Przejdź do głównej zawartości



Minimalistyczny selfhosting serwera fediverse


To na razie tylko pusty #raspberrypi zero W w obudowie i z kamerą .
W tej chwili zamienia się w eksperymentalny serwer #fediverse.
Cel: Sprawdzenie na ile taki serwer będzie używalny - dla jednego użytkownika.
Platforma do eksperymentu: #debian linux + #yunohost.
Do sprawdzenia wszystkie projekty które mają przygotowane pakiety pod YH i potrafią "rozmawiać" przez #activitypub.
Niektóre z góry odpadną ze względu na wymagania sprzętowe - #rpizero ma tylko 512 MB RAM - czyli np. o mastodonie można od razu zapomnieć.
Inne odpadną ze względu na brak wsparcia dla architektury procesora - 32 bit armv6.
Jeszcze inne mogą się zainstalować i uruchomić ale będą zbyt wolne, żeby generować odpowiedzi na żądania w sensownym czasie - #rpizero ma jednordzeniowy procesor z zegarem 1 Ghz.
Do tego dochodzi ograniczona szybkość karty SD i wifi - maksymalny realny transfer po wbudowanym wifi w #rpizero to ok ~20Mbits/s.
@SP6MR ⚡ Sam projekt wygląda interesująco, ale jeśli mam sobie zbudować kompilator , którego instrukcja zaczyna się od "To compile Crystal, you need Crystal :)." to chyba nie będę się wgłębiać dalej. Tu jest np przeciwna informacja do twojej: https://pi3g.com/2018/12/21/crystal-alpine-on-the-raspberry-pi/
Pozostaje czekać, aż ekipa od Crystala coś ogarnie w kierunku tego, żeby crosskompilacja była przyjemniejsza 😉








Below I will outline improvements for data interoperability regarding Wilderness Study Areas in the United States: https://en.wikipedia.org/wiki/Wilderness_study_area



A few days ago, I asked the community about converting general GIS polygons into OSM multipolygon relations. I’ve searched online but havent found a workflow that fits my needs.





I’m planning to update and expand the administrative boundaries for Bali in OSM. I’ve already prepared the multipolygons for admin_level 5, 6, and 7 using single shared ways for efficiency. By leveraging Google Sheets, I’ve also compiled a comprehensive list of Wikidata, Wikipedia links, and multilingual names to better serve Bali’s international profile.

However, the conflation process is proving to be a challenge. The existing data is quite a “nightmare” to clean up; many roads and waterways are currently shared with administrative relations, and landuse or natural features are glued to the boundaries. Time to start untangling!




















Mapping administrative boundaries in Indonesia can tricky especially when dealing with overlapping names. Here is my simplified workflow for preparing this data:

1. Data Sourcing


First, download the official spatial data from Peta Rupa Bumi by Badan Informasi Geospasial. This serves as the primary geometry source.

2. Extracting Place Nodes


Since the source data is in polygon format, I use QGIS to extract the centroids (points). These points are essential for creating the place=* tags that represent the center of each administrative area.

3. The Importance of Kemendagri Codes


The polygons include Kemendagri reference codes. These are vital for:

  • Conflation: Ensuring data matches across different sets.

  • Identification: Many villages (admin_level 7 or 8) share the same name. The code helps distinguish them within a Regency or Province.

4. Enriching Metadata


Using spreadsheet tools and conflation techniques, I cross-reference the data to add:

  • wikidata and wikipedia tags.

  • Multilingual names (name:en, etc.).

5. Geometry Processing


To follow OSM best practices, I convert the polygons into independent ways (polylines).

  • This allows adjacent areas to share a single boundary line via a multipolygon relation.

  • Once converted, I export the result as a .geojson file.

6. Final Tagging


Finally, I use the previously extracted place nodes to quickly copy and paste the relevant tags into the new multipolygon relations in my OSM editor.