Wb die name tag op landuse=residential daar ben ik ook tegenaan gelopen bij mijn OFM Garmin kaarten. Ze hadden oorspronkelijke een name tag, boundary en place tag. Bij veel plaatsen heb ik onzinnige boundary en place tag verwijderd (veel dorpen waren getagd met boundary=town of zelfs place=city) en name vervangen door AND_name. Op mijn OFM pas ik verder een filter toe op landuse=residential en AND_c=* (de meeste landuse=residentals hebben nog een AND_c ID) dus daar kan je de namen ook mee wegfilteren in je renderer, voor zover men die AND_c niet heeft verwijderd of gaat verwijderen.
Ik heb enkele maanden geleden de name tag verwijderd van de landuse=residential van Eindhoven en een paar dorpen in de buurt. Toen werden de namen ook al dubbel gerenderd, maar door het kleinere lettertype viel het niet zo op. Volgens het principe One feature, one OSM element leek het me niet correct om een plaatsnaam zowel op een place node als op een landuse=residential te hebben. Ik hoor graag hoe anderen hierover denken.
Ik ben het geheel met Cavit eens: ik verwijder de name=tags ook van de landuse=residential en laat de place-node staan.
Vaak staat die place-node overigens ook vast aan een knooppunt van wegen. In dat geval week ik hem los en verwijder de AND referenties tevens.
De rest van de tags laat ik staan.
Overigens valt het me ook op dat vele malen landuse=residential area’s als layer=-1 grof over alle andere landuse heen getrokken wordt en er zo dus overlap ontstaat.
Rendering is wellicht correct, maar we mappen niet voor de renderer, dus…?
Even gekeken op de Zuid Hollandse eilanden.
Er zijn behoorlijk wat plaatsen die nu dubbele namen hebben. Ook de buurtschappen komen nogal dubbel naar boven en dat stoort eigenlijk meer dan bij grotere plaatsen.
Wat wel opvalt dat er een aantal plaatsen (Rockanje en Ouddorp) zijn niet dubbel weergegeven worden. Daar lijkt de plaats van de node overeen te komen met waard de landuse z’n naam wil renderen. Tussen het zoomen op level 14/15 zie je de ene (zwart) verdwijnen en de ander (grijs) verschijnen.
De meeste plaatsen lijken nog een landuse=residential met name tag (overpass query: blauwe vulling: heeft een name; rode rand: heeft AND_c en/of AND_boundary tag) te hebben. Slechts een paar plaatsen waar de name tag van de landuse verwijderd is (of er nooit opgezeten heeft).
Een paar steekproeven in de rest van het land laten hetzelfde beeld zien.
Er zijn best wel wat gevallen waar de AND_c en AND_boundary tags niet meer aanwezig zijn.
Lijkt het beste om inderdaad de name tag te verwijderen van deze landuse tags OF de place nodes over te zetten naar de landuse (de place tag mag tenslotte ook op een area volgens de wiki).
Een plaats is vaak niet een punt, maar een gebied. Dus de landuse gebruiken (hetgeen vaak de bebouwde kom lijkt te zijn) lijkt niet eens onaardig. Als dan wegens nieuwbouw de bebouwde kom groeit blijft de naam ongeveer centraal in het gebied staan (taggen voor de renderer).
We renderen momenteel place=* alleen op nodes, niet op areas, omdat in veel landen plaatsen dubbel getagd zijn op zowel nodes als areas. Rendering place=* op areas zou leiden tot dubbele namen in die landen.
Door de place=* op een node te plaatsen kunnen we de plaatsnaam in het centrum van de plaats renderen, in plaats van in het midden van de polygon. Ik dacht eerst dat dat een voordeel was, maar nu ben ik niet meer zo overtuigd. Het voordeel van de dubbele rendering is dat we het nu mooi kunnen vergelijken: de zwarte roman letters van place=* staan op de node (die normaal in het centrum staat), en de cursief grijze letters van de landuse=residential polygon staan in het midden van de area. Een aantal plaatsen waar ze ver van elkaar liggen: Urk, Eibergen, IJsselmuiden, Hattem. Welke plaatsing vinden jullie mooier?
Overig is de AND landuse=residential tag sowieso een beetje vreemd, omdat het de hele bebouwde kom bevat, inclusief de industriegebieden. In Etten-Leur, het halve dorp is industriegebied bijvoorbeeld, en je zou verwachten dat dat niet in de landuse=residential zat.
Misschien is het beter om niet over “landcover”, maar gewoon over landuse te spreken, want dat is volgens mij de key die je hebt gebruikt.
Er is nog geen goed uitgewerkt tagging scheme voor landcover. De landcover OSM wiki pagina (http://wiki.openstreetmap.org/wiki/Landcover) lijkt wel mooi, en geeft een uitgebreid schema, maar feitelijk is dit slechts een Wiki pagina die gaat over “het probleem” en over de NLCD92 of andere bestaande landcover classificaties als “mogelijke” oplossing. Nergens echter op die pagina wordt een strak tagging schema opgezet, zoals dit eigenlijk zou moeten en ook op andere pagina’s gebruikelijk is. Daarmee vind ik deze pagina een beetje misleidend en een risico, omdat mensen nu dus maar wat “gaan doen”, i.p.v., of het nou goed of slecht uitgewerkt is, toch in ieder geval een bepaalde “standaard” te volgen.
Dit raakt aan een kernprobleem rond landuse / landcover en meer algemeen het vertalen van de werkelijkheid naar de abstractie van een kaart:
Enerzijds zijn er objecten waarvan de grenzen redelijk makkelijk als zodanig herkenbaar zijn, omdat ze een fysiek voorkomen hebben. Denk daarbij aan landcover zaken : “sand”, “grass”, “trees”, “rock”, “water”. Dit zijn fysieke “features” die meestal (maar zeker niet altijd) vrij goed te begrenzen zijn vanaf luchtfoto’s of “in het veld”.
Anderzijds zijn er objecten die weliswaar worden “ervaren” als landcover, maar die vaak niet een fysiek voorkomen hebben en eigenlijk “administratieve” grenzen zijn: “beach”, “meadow”, “forest”, “quarry”, “sea”.
“Forest” geen landcover hoor ik je denken?.. Maar kun jij mij de harde grens van de “Hoge Veluwe” als forest aanwijzen, anders dan het door de beheerder uit de pols ingetekende lijntje?! Binnen die grens kunnen ook vele objecten uit de 1e classificatie voorkomen! De administratieve grens van een forest kan trees, sand, grass en water omvatten, of zelfs een gehucht…
De objecten uit de tweede reeks liggen dichter bij de landuses, de eerste bij de landcovers. We gebruiken een stuk kaal “zand” (= landcover), om op te recreëren door op het “strand” (= landuse) te liggen zonnen of baden …
Helaas worden deze twee in landcover classificaties vaak gemixt, en is er ook een “grijs gebied”. Het abstraheren van de werkelijkheid naar een kaart, is niet altijd makkelijk of eenduidig
Ook betekent het, dat in classifficatie systemen waarin deze 2 zaken worden gemixt (waaronder die van OSM landuse), landuses en landcovers dus ook terecht over elkaar kunnen liggen.
Die AND landuse hoort eigenlijk geen residential te zijn, maar bebouwd gebied. En dan zijn ze vaak nog erg beroerd ingetekend.
Zie ook http://forum.openstreetmap.org/viewtopic.php?id=25189
Het lijkt me niet juist de place nodes te verplaatsen naar die AND landuses. Die zouden eigenlijk op termijn moeten worden vervangen door bv de data van het cbs (bestand bodemgebruik) waar je ‘woongebied’ als equivalent van residential zou kunnen gebruiken. Oa die van Almere heb ik op die manier vervangen.
Ik enkele vragen over wanneer wel of niet namen van gebieden verschijnen (en waarom pas bji een bepaalde zoom).
Bv. : http://www.openstreetmap.org/#map=14/51.4599/6.1598&layers=N
De naam Houthuizerheide (288182741) staat bij het natuurgebied.
Het naam van het natuurgebied Schuitwater (83386525) verschijnt niet.
Heel exact kan ik je dit niet aangeven, hiervoor moet je bij de beheerders van de “style” van OpenStreetMap zijn (o.a. Math1985), op de GitHub pagina van OpenStreetMap carto, wat de plek is waar deze wordt beheerd: https://github.com/gravitystorm/openstreetmap-carto/issues.
Ik denk echter dat het een combinatie is van een aantal factoren: labels verschijnen pas bij een bepaald zoomniveau, en zijn daarnaast afhankelijk van andere factoren zoals de grootte van het gebied, en de aanwezigheid van andere labels die wellicht hogere prioriteit hebben. In dat laatste geval, kan een label dus verwijderd worden, als een label dat belangrijker wordt geacht, conflicteert qua plaatsing met die van een minder belangrijk label.
In dit specifieke geval van bedrijventerrein Berghem, denk ik dat het label van het wegnummer (N556), de plaatsing van de naam van het bedrijventerrein tegenhoudt op zoomniveau 14, omdat het deels over het bedrijventerrein heen ligt op dit zoomniveau, en er op dit zoomniveau dan te weinig ruimte voor het bedrijventerrein label over blijft. Als je naar de andere twee bedrijventerreinen kijkt, zul je opmerken dat de weglabels daar niet een probleem vormen, bij het industrieterrein Hoogveld b.v., vallen de weglabels, netjes om het naamlabel heen.
Al deze restricties op de labeling zijn echt noodzaak, omdat anders de kaart volledig overspoelt wordt door labels en door overlappingen van labels onleesbaar zou worden, maar de labeling wordt daardoor inderdaad wel wat “onvoorspelbaar” voor je menselijk gevoel… (de renderserver van OSM rekent het gewoon logisch uit op basis van de in de style vastgelegde regels…)
Ik denk niet dat de naam van 288182741 wordt gerenderd, maar dat de naam Houthuizerheide afkomstig is van 160020600. Als je verder inzoomt (level 16) zie je de naam nog een keer verschijnen. Deze keer lijkt hij mij afkomstig van 160020599.
Het verschil zit er in dat de twee laatstgenoemden getagt zijn als “landuse=forest” en 288182741 is getagt als “toponym=forest” ook natuurgebied Schuitwater 83386525 is getagt als “toponym=forest”.
Ik ga ervan uit dat hier het probleem zit. Het lijkt er op dat de naam van “toponym=*” helemaal niet gerenderd word; een korte zoektocht heeft mij iig geen voorbeelden opgeleverd die het tegendeel aantonen.
toponym=* is ook nergens fatsoenlijk gedocumenteerd als tag, en alszodanig ook niet echt erkend, dus vrij logisch dat het niet gerenderd / gelabeled wordt. Dat is niet zo vreemd, als je de - tevens Nederlandse - oorsprong van die tag leest, zie hier:
Namen van landcovers veschijnen als er aan twee voorwaarden voldaan is: het minimale zoomlevel (wat afhankelijk is van de grootte van het gebied) moet bereikt zijn, en er moeten niet al labels met een hogere prioriteit gerenderd zijn op dezelfde plek.
Bedrijventerrein Berghem clasht met het label van de weg. We zouden namen van bedrijventerreinen hogere prioriteit kunnen geven dan wegnummers, maar dan gaan mensen zich weer afvragen waarom de wegnummers ontbreken.
Toponym=* renderen we momenteel niet, en is momenteel ook niet geladen in de database.
Zou je met http://bl.ocks.org/tyrasd/raw/6164696/ kunnen controleren of er inderdaad iets veranderd is, en zo ja, een link naar de betreffende locatie kunnen geven?
Ik denk dat een spaarzamere labeling van de wegen, b.v. door het afdwingen van een minimale afstand tussen labels van “x” pixels, al veel zou schelen. Volgens mij hadden jullie hier al een issue voor openstaan op GitHub, iets op basis van samenvoegen van wegsegmenten, en dan pas labelen, als mogelijke oplossing??
Helaas, ik zie ze ook niet meer op de oude Mapnik laag, waarschijnlijk al eerder verdwenen. Ik meen me te herinneren dat er ooit ook adminstrative boundaries van gemeenten en plaatsnamen werden gerenderd (leidde ook tot dubbele namen, zelfs namen in drievoud).
Helemaal mee eens. Check bij het losknopen van de place nodes wel even of deze nog lid zijn van een relatie. Ik ben bezig om role=admin_centre toe te voegen aan de gemeente relaties. De role geeft aan welke plaats de hoofdplaats van een gemeente is (zie ook wikipedia en http://wiki.openstreetmap.org/wiki/Tag:type=boundary)). Daarbij heb ik er niet aan gedacht om de place-node meteen los te knopen van de wegen.
In OSM wordt geen duidelijk onderscheid gemaakt tussen landcover enerzijds, en landuses of boundaries (in de zin van puur grenzen van gebieden!) anderzijds. Er zijn “tags” die als een vorm van landcover als gevulde polygonen / vlakken worden gerenderd, die eigenlijk alleen een omringend lijntje / outline zouden moeten hebben. Omdat het echter als gesloten vlak wordt gerenderd, wordt de “tag” inmiddels ook als zodanig gebruikt, maar dat conflicteerd dan soms met de definities gehanteerd door een overheidsorganisatie waarvan je een import wilt doen.
Zo kan het zijn dat een beheerder de eigendomsgrenzen van bepaalde bossen wil invoeren, b.v. een fictief bos genaamd “Lutjebroeker bos”. Maar dat zijn eigenlijk administratieve / kadastrale grenzen. Voer je dat nu in met landuse=forest, dan wordt het doodleuk als gesloten vlak gerenderd, omdat bij OSM die tag eigenlijk voor een gesloten stuk met bomen staat. Dan verdwijnt dus alles onder het bosvlak als je pech hebt.
Je moet dus opletten hoe je hiermee omgaat, en niet administratieve grenzen taggen met tags, die eigenlijk een landcover voorstellen of zo worden gerenderd.
Dit alles is eerlijk gezegd ook niet zo makkelijk, en ook wereldwijd worden hierbij door grote overheidsinstanties op het gebied van de kartografie fouten gemaakt, of simpelweg moeilijkheden ondervonden bij het opstellen van een “datamodel”.
Om terug te komen bij je vraag “Hoe tag je een natuurgebied dat bestaat uit een combinatie van bos, gras, heide en water zodat de naam wel op de kaart verschijnt?”: ik denk dat dergelijke beheersgebieden, in Nederland toch altijd wel een of andere beschermde status hebben.
Die dubbele namen zijn dan waarschijnlijk de reden dat de namen niet gerenderd worden. Dat zal dan eerst in de data moeten worden opgelost. Wel renderen we namen van admin boundaries nu langs de admin boundaries zelf, maar alleen tot level 10. Zou het helpen om ook level 11-boundaries te renderen?
boundary=protected_area wordt momenteel niet gerenderd, de oudere tag leisure=nature_reserve wel.
Die wijkgrenzen hoeven m.i. niet gerenderd te worden, de kaart is toch al zo vol. Wijknamen zou wel handig zijn maar zou dan dus met een node (place=suburb?) moeten.
