Aangepaste gestileerde kaarten maken met OpenStreetMap - Ajarnpa

2024 Auteur: John Day | [email protected]. Laatst gewijzigd: 2024-01-30 11:15

In deze instructable zal ik een proces beschrijven waarmee u uw eigen op maat gemaakte gestileerde kaarten kunt genereren. Een gestileerde kaart is een kaart waarop de gebruiker kan specificeren welke gegevenslagen worden gevisualiseerd, evenals de stijl waarmee elke laag wordt gevisualiseerd. Ik zal eerst het proces beschrijven waarmee je software kunt schrijven om kaarten te stylen, gevolgd door een voorbeeld van de Python-software die ik heb geschreven om deze taak uit te voeren.

De volgende video laat zien hoe ik persoonlijk gestileerde kaarten genereer, maar blijf lezen voor de intieme details. Ik ben erg benieuwd wat de community creëert!

Wat is mijn drijfveer achter dit project?

Eerlijk gezegd ben ik aan dit project begonnen omdat ik dacht dat het leuk zou zijn om te doen. Dit idee spookte het afgelopen jaar door mijn hoofd en ik heb eindelijk de tijd genomen om het uit te voeren. Na een dag prototyping met wat basisscripts, was ik in staat om zeer veelbelovende resultaten te genereren - zo veelbelovend dat ik wist dat ik mijn scripts moest formaliseren zodat anderen gemakkelijk hun eigen creaties konden maken.

Mijn motivatie bij het schrijven van deze instructable is te wijten aan het feit dat ik zeer minimale informatie heb gevonden over hoe je je eigen gestileerde kaarten helemaal opnieuw kunt maken. Ik hoop wat ik heb geleerd te delen met de gemeenschap.

Bronnen/links:

• OpenStraatkaart
• OpenStreetMap Legalese
• Github-opslagplaats

Benodigdheden

• Een Python-distributie (ik gebruikte Anaconda & Python 3.6)
• PyQt5 (voor de GUI-afhankelijkheden)

Stap 1: Het proces definiëren I: Het OSM-bestand downloaden

Toen ik voor het eerst aan dit project begon, was de meest in het oog springende vraag: "Waar kan ik kaartgegevens krijgen?" Natuurlijk dacht ik, zoals je zou verwachten, meteen aan Google Maps. Na grondig onderzoek ontdekte ik dat Google echt niet wil dat mensen met hun gegevens spelen, in creatieve zin of anderszins. In feite verbieden ze web-scraping van Google Maps expliciet.

Gelukkig was mijn wanhoop van korte duur toen ik OpenStreetMap (OSM) ontdekte. OSM is een samenwerkingsproject waarbij mensen over de hele wereld gegevens aanleveren. OSM staat expliciet open-end gebruik van hun gegevens toe in naam van Open Source-software. Als zodanig is het bezoeken van de OSM-webpagina waar de reis voor het stileren van de kaart begint.

Nadat u op de OSM-website bent aangekomen, klikt u op het tabblad "Exporteren" om de kaartexporttools weer te geven. Zoom nu in om de regio te bekijken waarin u geïnteresseerd bent in het verzamelen van kaartgegevens. Selecteer de link "Handmatig een ander gebied selecteren", waardoor een vak op uw scherm verschijnt. Vorm en plaats deze doos over het interessegebied. Als u tevreden bent, klikt u op de knop "Exporteren" om uw gegevensbestand van OSM te downloaden.

Opmerking #1: Als uw geselecteerde regio te veel gegevens bevat, krijgt u een foutmelding dat u te veel knooppunten heeft geselecteerd. Als dit u overkomt, klikt u op de knop "Overpass API" om uw grotere bestand te downloaden.

Opmerking #2: Als uw gedownloade OSM-bestand groter is dan 30 MB, zal het Python-programma dat ik heb geschreven merkbaar traag zijn. Als je vastbesloten bent om een groot gebied te gebruiken, overweeg dan een script te schrijven om overbodige gegevens weg te gooien die je niet van plan bent te tekenen.

Stap 2: Het proces definiëren II: de gegevens begrijpen

"Ik heb de gegevens… wat nu?"

Begin met het openen van uw gedownloade OSM-bestand in uw favoriete tekstbewerkingssoftware. Je zult eerst merken dat dit een XML-bestand is, wat geweldig is! XML is eenvoudig genoeg om te ontleden. Het begin van uw bestand zou er bijna identiek moeten uitzien als de eerste afbeelding van deze stap - enkele basismetadata en geografische grenzen zullen worden vermeld.

Terwijl u door het bestand bladert, ziet u drie gegevenselementen die overal worden gebruikt:

1. Knooppunten
2. Manieren
3. Relaties

Het meest elementaire gegevenselement, een knooppunt, heeft eenvoudigweg een unieke identificatie, breedtegraad en lengtegraad. Natuurlijk zijn er aanvullende metadata, maar we kunnen deze veilig weggooien.

Ways zijn verzamelingen van knooppunten. Een weg kan worden weergegeven als een gesloten vorm of als een open lijn. Ways bestaan uit een verzameling knooppunten die worden geïdentificeerd aan de hand van hun unieke identificatiecode. Ze zijn gelabeld met sleutels die de gegevensgroep definiëren waartoe ze behoren. De manier afgebeeld in de derde afbeelding hierboven behoort bijvoorbeeld tot de gegevensgroep 'plaats' en de subgroep 'eiland'. Met andere woorden, deze specifieke manier behoort tot de laag "eiland" onder de groep "plaats". Manieren hebben ook unieke identifiers.

Ten slotte zijn relaties verzamelingen van manieren. Een relatie kan een complexe vorm vertegenwoordigen met gaten of met meerdere regio's. Relaties hebben ook een unieke identificatie en worden op dezelfde manier getagd als manieren.

U kunt meer lezen over deze gegevenselementen op de OSM-wiki:

• Knooppunten
• Manieren
• Relaties

Stap 3: Het proces definiëren III: de gegevens verteren

Nu zou u op zijn minst een oppervlakkig begrip moeten hebben van de gegevenselementen waaruit een OSM-bestand bestaat. Op dit moment zijn we geïnteresseerd in het lezen van de gegevens van OSM in de taal van uw keuze. Hoewel deze stap Python-gecentreerd is, moet je dit deel toch lezen als je Python niet wilt gebruiken, omdat het een paar tips en trucs bevat.

Het xml-pakket wordt standaard meegeleverd met de meeste standaard Python-distributies. We zullen dit pakket gebruiken om ons OSM-bestand heel gemakkelijk te ontleden, zoals weergegeven in de eerste afbeelding. In een enkele for-lus kunt u de verwerking van OSM-gegevens voor elk specifiek gegevenselement verwerken.

Op de laatste regel van de afbeelding ziet u dat ik controleer op de tag 'bounds'. Deze stap is van vitaal belang bij het vertalen van de breedte- en lengtegraadwaarden naar pixels op het scherm. Ik raad ten zeerste aan deze conversie uit te voeren op het moment dat u het OSM-bestand laadt, aangezien de massaconversie van gegevens procesintensief is.

Over het converteren van breedte- en lengtegraden naar schermcoördinaten gesproken, hier is een link naar de berekeningsfunctie die ik heb geschreven. U zult waarschijnlijk iets vreemds opmerken bij het converteren van breedtegraad naar schermcoördinaten. Er is een extra stap bij betrokken in vergelijking met de lengtegraad! Het blijkt dat OSM-gegevens worden gemodelleerd met behulp van de Pseudo-Mercator-projectiemethode. Gelukkig heeft OSM hier fantastische documentatie over dit onderwerp, en ze bieden de breedtegraadconversiefuncties voor een aanzienlijk aantal talen. Geweldig!

Opmerking: in mijn code is schermcoördinaat (0, 0) de linkerbovenhoek van het scherm.

Stap 4: Implementatie van Python Map Stylizer

Tot nu toe heb ik het gegevensbestand van OSM besproken - wat het is, hoe het te lezen en wat ermee te doen. Nu zal ik de software bespreken die ik heb geschreven om stilistische kaartvisualisatie aan te pakken (GitHub-opslagplaats in de inleiding).

Mijn specifieke implementatie is gericht op gebruikerscontrole van de rendering-pipeline. In het bijzonder sta ik de gebruiker toe om de lagen te selecteren die ze zichtbaar willen maken en hoe ze die laag willen visualiseren. Zoals ik eerder kort vermeldde, zijn er twee klassen van weergegeven elementen: opvulitems en regelitems. Opvullingen worden alleen gedefinieerd door een kleur, terwijl lijnen worden gedefinieerd door kleur, lijndikte, lijnstijl, lijnkapstijl en lijnverbindingsstijl.

Wanneer de gebruiker wijzigingen aanbrengt in laagstijlen en zichtbaarheid, worden de wijzigingen weergegeven in de kaartwidget aan de rechterkant. Zodra een gebruiker het uiterlijk van de kaart naar tevredenheid heeft aangepast, kan hij de maximale kaartafmetingen aanpassen en de kaart als afbeelding op zijn computer opslaan. Bij het opslaan van een afbeelding wordt ook een gebruikersconfiguratiebestand opgeslagen. Dit zorgt ervoor dat een gebruiker de configuratie die hij heeft gebruikt om een bepaalde afbeelding te genereren op elk moment kan oproepen en hergebruiken.

Stap 5: Implementatie Nadeel + Oplossing

Toen ik voor het eerst een kaart handmatig begon te stylen, ontdekte ik dat dit een nogal vervelend proces was. De gebruiker maximale controle bieden kan simpelweg overweldigend zijn vanwege het grote aantal beschikbare "knoppen". Er is echter een eenvoudige oplossing, die een beetje extra scripting met zich meebrengt.

Ik begon door te identificeren in welke lagen ik in het bijzonder geïnteresseerd ben. Laten we voor dit instructable zeggen dat ik het meest geïnteresseerd ben in gebouwen (allemaal), rivieren, hoofdwegen en straten aan de oppervlakte. Ik zou een script schrijven waarin ik een instantie van configuratie maak, laagstatussen op de juiste manier wissel met de functie setItemState() en gedefinieerde constanten, en kleuren instellen op basis van hoe ik wil dat mijn lagen verschijnen met behulp van de setValue(). Het resulterende configuratiebestand dat wordt opgeslagen, kan worden gekopieerd naar de map configs en door de gebruiker worden geladen.

Een voorbeeldscript staat in de afbeelding hierboven. De tweede afbeelding is een voorbeeld van hoe de helperfuncties eruit zouden zien, en aangezien ze in principe allemaal identiek zijn, alleen met verschillende constanten, heb ik slechts een afbeelding van één voorbeeld toegevoegd.

Stap 6: Gebieden voor verbetering

Na te hebben nagedacht over mijn software-implementatie, heb ik verschillende gebieden geïdentificeerd die nuttige verbeteringen zouden zijn voor ervaren gebruikers.

1. Dynamische laagweergave. Momenteel heb ik een vooraf gedefinieerde lijst met lagen die worden weergegeven, dat is alles. Een deel van de rechtvaardiging was de moeilijkheid om te bepalen of een laag een lijn of een vulling moest zijn. Als gevolg hiervan wordt u bij bijna elk OSM-bestand dat u opent begroet met een hele reeks waarschuwingen over lagen die niet worden weergegeven. Vaak zijn deze zo minimaal dat het geen probleem is, maar er zullen ongetwijfeld kritische lagen ontbreken. Dynamische laagweergave zou deze zorgen wegnemen.
2. Dynamische laagtoewijzing. Dit gaat hand in hand met #1; als u dynamische laagweergave wilt, hebt u dynamische laagtoewijzing nodig (d.w.z. het identificeren van een opvullaag versus een lijnlaag). Dit zou redelijkerwijs kunnen worden bereikt, zoals ik heb geleerd, omdat wegen waarvan het eerste en laatste knooppunt hetzelfde zijn, ingesloten paden zijn en daarom worden gevuld.
3. Kleur groepen. Een gestileerde kaart heeft vaak meerdere lagen die dezelfde stijl hebben, en als de gebruiker de stijl van een groep tegelijkertijd kan wijzigen, zou dit de tijd die de gebruiker besteedt aan het één voor één bewerken van lagen aanzienlijk verminderen.

Stap 7: Gedachten afsluiten

Bedankt iedereen voor het nemen van de tijd om mijn Instructable te lezen. Dit project vertegenwoordigt het hoogtepunt van vele uren onderzoek, ontwerp, programmeren en debuggen. Ik hoop dat ik een lanceerplatform heb kunnen bieden van waaruit je je eigen project kunt bouwen of voort kunt bouwen op wat ik al heb geschreven. Ik hoop ook dat mijn tekortkomingen en tips voldoende punten opleveren om rekening mee te houden in uw ontwerp. Als je minder geneigd bent om te programmeren en meer geneigd bent om kunstwerken te maken, zie ik graag wat je maakt in de reacties! De mogelijkheden zijn eindeloos!

Speciale dank aan de OpenStreetMap-bijdragers! Dergelijke projecten zouden niet mogelijk zijn zonder hun aanzienlijke inspanningen.

Laat het me weten als je vragen hebt in de comments!

Tweede plaats in de Maps-uitdaging