Zijn er regels voor POI ?

Vooreerst nog eens wat ik doe =


I live in Mechelen and work in Brussels.

I do Mozilla Stumbler, Mapillary and a little OSM.

In OSM I mainly maintain the notes for Brussels. I take picture for mappers. I do not do too much effort to resolve bad notes. I am not going to Google Search to understand what the lodger means. So I delete most of them. This is mainly because OSM allows notes to be made by people who are not logged in, and this for publicity reasons.

Ik heb al wat notes gewist omdat ze niet meer waren dan “CNRS” of “YINYAN”.

Ik heb intussen wat rondgekeken in de OSM data en zo zijn er eigenlijk veel. En de naam wordt bovendien nog gerenderd.

http://wiki.openstreetmap.org/wiki/Points_of_interest
http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
Het artikel “One feature - one element” is te ingewikkeld voor mij.
Ik heb de tagging samenkomst ik Gent gemist.
Ik zal maar aannemen dat het een jungle is en ik maar doe wat ik wil en dat iets beter is dan niets.

Een meer koncrete vraag = wanneer wordt een tag van een POI gerenderd ? Kan ik ergens de CSS zien ? Heeft het ook te maken met de nabijheid van een straatnaam ?
Zo krijgt dit snoepwinkeltje http://www.openstreetmap.org/node/3946185110#map=19/51.24879/2.96618&layers=N pas in zoomlevel 19 een naam. Supermarkt Proxy Delhaize heeft al eerder recht op een naam. Ik betwist dit niet, ik zou alleen graag weten in welke file dat bepaald wordt.

Beste Philippec, bedankt iedere bijdrage maakt de OSM database vollediger. En nee ik ken geen file, nooit naar gezocht, maar verwacht met de keuze mogelijkheden geen helderheid of garantie.
Je vraagstelling lijkt er op of je de tags zo aan wil brengen om ze op ieder moment (zoomlevel) in beeld te krijgen, dat is in OSM bekend als taggen voor de renderer en is not done. De renderer maakt voor ieder zoomlevel een keus, wat wel en wat niet in beeld komt. Net als op een kaart 1:200.000 laat autowegen en steden zien, maar 1:10.000 laat alles zien inclusief gebouwen. Er zit dus een volgorde op de af te beelden POIs, maar er wordt steeds opnieuw gekozen voor een volgende zoomlevel afhankelijk van de hoeveelheid POIs. Vergelijk Aubel met Kortrijk, het monument komt bij level 17 in beeld en krijgt bij het hoogste level 19 een bijschrift en bushaltes komen bij level 16 in beeld maar bij 17 een naam andere pas bij 18, sommige POI eerder, de een wel en de ander niet. Afhankelijk van het aanbod, volgens de oude kartografische leer, weer geven is de kunst van het weglaten :wink:

Op deze plek in Den Haag zie je hetzelfde probleem:

De omcirkelde poi hebben een naam die niet zichtbaar is op de standard rendering. De reden is duidelijk, 2 namen kunnen niet over elkaar worden geplaatst. Welke naam de voorkeur heeft? Als een straatnaam moet worden weergegeven, dan gaat dat volgens mij voor, maar de regels voor wat er gebeurt als 2 poi elkaar in de weg zitten? Misschien kan @Math1985 daar wat over zeggen?
Maar daarom kijk je natuurlijk ook met OpenPoiMap:

Het belangrijkste: je kunt een POI mappen als node (punt) of als area/polygon. Het maakt op zich niet zo veel uit wat je doet, als je maar een van beide doet en niet een en hetzelfde POI zowel als punt of als polyon invoert.

Goede vragen. Dit is de stylesheet: https://github.com/gravitystorm/openstreetmap-carto/blob/master/amenity-points.mss
De regels voor winkels zijn eigenlijk heel simpel: supermarkten en department stores worden gerenderd vanaf z16, andere winkels vanaf z17. Namen en iconen worden echter nooit door elkaar heen getekend. De labels worden geprobeerd te renderen op volgorde straatnaam - POI als polygon - POI als punt. Als er bijvoorbeeld al een straatnaam staat, probeert de renderer niet daar nog een polygon-label overheen te printen. Ook hebben labels van grotere polygonen voorrang op labels van kleinere polygonen.

Hier de SOTM US presentatie van dit jaar.
http://stateofthemap.us/openstreetmap-carto/
Heel interessant voor de context, maar technische detailantwoorden geeft den Andy niet.

Ik heb een beetje gefoefeld, de node http://www.openstreetmap.org/node/39461 … 8&layers=N verder van de straat gebracht.
Noem het “taggen voor de renderer”, ik noem het “tender loving care”
Het is verbeterd. Z18 geeft het icoon voor confectionery en z19 geeft ook de naam.

Nochtans lees ik in de css

[feature = ‘shop_confectionery’][zoom >= 17] {
marker-file: url(‘symbols/confectionery-14.svg’);
marker-fill: @shop-icon;
marker-placement: interior;
marker-clip: false;

“>=” wil zeggen groter of gelijk aan.

Iemand die een snoepwinkel in Bredene zoekt zal niet naar z18 gaan en dan 5 keer schuiven met de kaart. Wanneer (dankzij een aankomende import ?) de huizen in die straat ingetekend zijn, zal ik de POI toekennen aan de building.

Ik ken ook iemand die een punt van een building geometry toekent aan een poi als er nog andere bezigheden in het pand zijn. Wat denken jullie daarvan ?

En als jullie niets te doen hebben, er zijn nu in Brussel 2 notes van de app Cruyzeby verschenen. Rommel volgens mij. http://www.openstreetmap.org/note/503453#map=15/50.8145/4.3859&layers=HN

Op Z18 ook al een naam, maar nog niet helemaal fraai:

Zo iemand kan natuurlijk ook OpenPoiMap gebruiken:

POIs toekennen aan gebouwen is volgens mij enkel gebruikelijk als het gebouw slechts 1 functie heeft. Indien er ook nog een woongedeelte is boven de winkel, kan je net zo goed een afzonderlijk punt in het gebouw laten staan.
Ik zie weinig of geen reden om de winkel en het gebouw te laten samenvallen. Sommigen zetten dat punt op de rand, waar de ingang is, anderen gewoon ergens in het gebouw.

In België zetten we de adres informatie gewoonlijk op het gebouw, in Nederland gebruikt men (meestal/gewoonlijk ?) afzonderlijke adrespunten. Je kan de adres informatie in België herhalen op de POI als je “eenvoudige” data-gebruikers (ie. software) wil helpen om toch adres informatie van de POI te tonen, zonder het gebouw met zijn adres te moeten opzoeken.

Als ik naar een winkel zoek, gebruik ik een zoek functie. Gewoon de kaart wat over en weer schuiven is dan niet echt efficiënt. Bovendien kan in dicht gemapte gebieden de node gewoon ontbreken omdat er een andere dichtbij staat. Een zoekmachine (zoals Marc Z. hierboven toont) heeft dat probleem niet.