Dubbele namen op panden.

Communities Nederland (Netherlands)
1

Tijdens het BAG import proces komen af en toe vragen naar boven borrelen, soms is het verstandig om deze dan te bespreken in de community.
Er wordt in de handleiding van de BAG import de volgende voorgesteld:

Op openstreetmap.org wordt niet elke poi gerenderd.
Als de name van de poi op de pandcontour staat, wordt deze altijd gerenderd, maar nu zie je de POI niet meer op openstreetmap.org.
Het is (naar mijn mening) duidelijker dat een POI (inclusief BAG adres gegevens) op een losse node wordt geplaatst. (zowel op OSM, Basecamp en JOSM)
Ik heb (bij wijze van proef) geprobeerd om de name=* tag dubbel te taggen, dwz op de POI en op de pandcontour. Dit heb ik inmiddels teruggedraaid omdat dit taggen voor de renderer zou betekenen. Tevens worden bij een zoekopdracht ook dubbele vermeldingen gevonden.

Nu weet ik dat taggen voor de renderer niet is gewenst, maar graag zou ik wat meer achtergrond informatie willen verkrijgen wat nu het beste is hoe POI’s te taggen.

2

Bedoel je hier nu te zeggen dat name=* op building=yes altijd voor alle POI iconen wordt gerenderd? Ook als het een POI is waarvoor normaal een icoon gebruikt wordt? Als dat zo is, dan is dat een bug in de stylesheet.

3

Ik ben inderdaad wat onduidelijk in de bewoording.
Als een losse node gebuikt wordt als POI, wordt niet elke POI gerenderd op openstreetmap.org
Om nu toch de naam te laten zien zou je kunnen overwegen om de name=* tag ook op het pandcontour te plaatsen.
Deze naam wordt in zo’n geval altijd gerenderd zonder dat hier een shop=* of amenity=* tegenover staat.
Wel is de name=* nu dubbel, nl. op de pandcontour en op de losse node.

Mijn vraag is:
Hoe bezwaarlijk is het dat er 2x de name=* tag gebruikt wordt voor één POI.

4

Ik denk dat het eerder gaat om het principe van “One feature, one OSM element”.

5

Als je alle tags van de POI naar het gebouw verplaatst (en de node verwijdert) dan dacht ik dat als de POI niet herkend wordt dat niets uit maakt. De combinatie name= + building= wordt dan gerenderd.

Na een hoop zoeken heb ik hier in Houten een POI te gevonden die niet wordt gerenderd en waar er maar één adres in het gebouw zit, dus ik kan het testen. De tag shop=second_hand heeft geen icon, maar de Kringloopwinkel hier wel een naam: http://www.openstreetmap.org/way/278252456#map=19/52.02307/5.15628

6

Ook zo een voorbeeld met leisure=marina
http://www.openstreetmap.org/#map=18/52.87960/5.37276
waarbij de polygon haven leisure=marina heeft
maar de node in deze leisure=marina had, welke ik verwijdert heb en nu zie je dus geen node met een symbol.
Validatie josm, in Josm verdwijnt ook het symbool.
En de naam is niet zichtbaar openstreetmap.org

Hier dan wel de “name” op de node zichtbaar.
http://www.openstreetmap.org/#map=19/52.88480/5.40712
Heeft dan te maken met de overige tags of de naam wel of niet zichtbaar wordt bij de node.
harbour=yes

Hier is de node wel zichtbaar in Josm door een leisure=marina tag op de node.

http://www.openstreetmap.org/#map=17/52.87474/5.36612

Hier zat ik dus te dubben of ik die dubbele tags weg zou halen.

Dit ook in verband met de openseamap hoek van contributers.

7

zit dat in de shop=* tag of de building=retail tag, daarnaast is een office waterschap

8

Dit is zeker niet onbelangrijk, bedankt voor de vermelding. Op deze good practice pagina stonden nog meer wetenswaardigheden waar ik nog niet van had gehoord.

Toch even terugkomend op de vraagstelling.
Zoals Allroads beschrijft is excact wat ik bedoel.

  1. Op de één wordt de naam niet gerenderd. leisure=marina op een node wordt op openstreetmap.org niet gerenderd, dus de naam ook niet. (of is deze conclusie onjuist?)
  2. Op de ander wel, hierbij wordt de “leisure=marina” key op een aparte node geplaatst.

Bij 1. staat de naam op de node
Bij 2. staat de naam op de area

Volgens mij is dit een juiste manier om de name te laten verschijnen en de key (leisure/aminety/shop etc.) op een node te plaatsen zonder de naam op deze node te plaatsen.
“One feature, one OSM element” wordt niet geschonden.

Of is dit een vorm van taggen voor de renderer?

9

Deze conclusie is onjuist in een voorbeeld van Allroads staat leisure=marina op een losse node en de naam wordt wel gerenderd.

10

shop doet niets. building wel. Kijk maar naar het lettertype.

Er wordt hard gewerkt aan een rendering voor bijna alle winkels, maar die is nog niet in productie. In de productie zijn er alleen regels voor een beperkt aantal waarden van shop.

leisure=marina is een heel ander verhaal wat rendering betreft. De originele vraag gaat over zaken zonder eigen renderregels. Voor leisure marina zijn er duidelijke renderregels. leisure=marina op een vlak geeft een blauwe rand in mapnik. In JOSM worden vlakken met een kleurtje gedaan en alleen punten met een icoontje.

In je eerste voorbeeld (SkipsMaritiem - Marina Stavoren) staat leisure=marina op het vlak en alle andere tags van de marina op een node. Er is geen enkele mogelijkheid voor de renderer of JOSM om te snappen dat dat bij elkaar hoort.

Edit: dit was dus getypt voor ik de posts van Comodoortje kon lezen.

11

Mag je in de voorbeelden waar nog geen rendering voor is, de name=* op het pandcontour zetten?
Terwijl op de losse node shop=* wordt geplaatst?

12

Voorbeeld 2
staat de naam niet op de area, wel op de node maar doordat daar de tag harbour=yes op staat wordt hij gerendeert.

Mijn dubio is nog steeds heb ik er goed aan gedaan om dubbele leisure=marina weg te halen van de node.

Door het weghalen, hoe veranderen dan andere kaarten.
Je ziet daar ook dat de zeejongens aan het taggen zijn seamark:name

http://map.openseamap.org/?zoom=17&lat=52.87974&lon=5.37529&layers=BFTFFFTFFTF0FFFFFFFF
node:
name=SkipsMaritiem - Marina Stavoren
phone=+31 514 684684
seamark:harbour:category=marina
seamark:name=SkipsMaritiem - Marina Stavoren
seamark:type=harbour
website=http://www.skipsmaritiem.nl/de/jachthavens/marinastavoren/

Je ziet daar nu dat twee schipjes symbolen gerendeert worden.
En de naam nu twee keer, vanwege waarschijnlijk
name=
seamark:name=

Kaart is maar net hoe oud de data is .

13

Klopt, het ging mij persoonlijk om shop=* die lang niet allemaal gerenderd worden.

14

Ja, ik geef eigenlijk een verkeerd voorbeeld.

Ik meen begrepen te hebben, dat nodes binnen een polygon wel een verband met elkaar hebben.

binnen gebouw binnen marina

15

Alles mag :wink:

Ik ben echter een sterk voorstander van “One feature, one OSM element”. Er is volgens mij ook geen enkele reden wat renderen betreft om niet alle tags op het pand te zetten als er maar één adres in het pand zit. Zitten er meerdere adressen in het pand, dan is het denk ik gewoon even een paar weken geduld hebben en verschijnen ze vanzelf.

16

Dit begrijp ik niet helemaal.
Als er meer adressen in een pand zijn, (ik neem even als voorbeeld een winkelstraat) dan zijn meestal de bovenwoningen de andere adresnodes.
Ik vind dat de naam van de winkel op het pandcontour mag komen te staan, om de naam van de shop te laten renderen.

17

Is het een dataprobleem of een renderprobleem? Oplossing voor een dataprobleem is de data juist taggen. Als een gebouw inclusief bovenliggende verdiepingen één winkel omvat is het vanuit dataoogpunt prima om alle POI info op de gebouwcontour te zetten. In andere situaties is een node beter, omdat één gebouw dan meerdere functies heeft (diverse winkels, apartementen vanaf de eerste verdieping etcetera).
Oplossing voor een renderprobleem is de rendering aanpassen via de OSM carto.

18

“One feature, one OSM element” dus automatisch omgekeerd “More features, more OSM elements”.

In dit geval:

  • één pand
  • één woning
  • één winkel

Elk van die features heeft properties. De naam van de winkel is een property van … de winkel of het pand? Het lijkt mij dat het antwoord daarop evident is.

Is het renderen van die namen echt zo belangrijk dat we niet kunnen wachten tot het opgelost is waar het hoort: Zie Render a generic icon for shop=*. Als je nu eerst alles fout mapped, moet je het straks allemaal weer terugdraaien. Voor de naam van een gebouw wordt een heel ander lettertype gebruikt.

We hebben toch ook allemaal braaf tunnel=building_passage gemapped i.p.v. tunnel=yes maanden voordat die building_passage werd gerenderd.

19

Ter informatie: volgens het huidige voorstel zullen binnenkort de volgende waarden voor shop=* gerenderd worden:

accessories, alcohol, antiques, appliance, art, baby_goods, bag, bakery, bathroom_furnishing, beauty, bed, beverages, bicycle, boat, bookmaker, books, boutique, builder, building_materials, butcher, camera, car, car_parts, car_repair, car_service, carpet, charity, cheese, chemist, chocolate, clothes, coffee, communication, computer, confectionery, convenience, copyshop, cosmetics, craft, curtain, dairy, deli, department_store, discount, dive, doityourself, dry_cleaning, e-cigarette, electrical, electronics, energy, erotic, estate_agent, fabric, farm, fashion, fishing, flooring, florist, food, frame, frozen_food, funeral_directors, furnace, furniture, gallery, games, garden_centre, gas, general, gift, glaziery, greengrocer, grocery, hairdresser, hardware, health, health_food, hearing_aids, herbalist, hifi, hobby, household, houseware, hunting, ice_cream, insurance, interior_decoration, jewelry, kiosk, kitchen, laundry, leather, lighting, locksmith, lottery, mall, massage, medical, medical_supply, mobile_phone, money_lender, motorcycle, motorcycle_repair, music, musical_instrument, newsagent, office_supplies, optician, outdoor, paint, pastry, pawnbroker, perfumery, pet, phone, photo, photo_studio, photography, pottery, printing, radiotechnics, real_estate, religion, rental, salon, scuba_diving, seafood, second_hand, sewing, shoe_repair, shoes, shopping_centre, solarium, souvenir, sports, stationery, supermarket, tanning, tattoo, tea, ticket, tiles, tobacco, toys, trade, travel_agency, tyres, vacuum_cleaner, variety_store, video, video_games, watches, wholesale, wine, winery, yes.

20

Het is een render “probleem”. Inmiddels heb ik me redelijk ingelezen en mede dankzij jullie weer een paar stappen verder in de logica.

Helemaal mee eens, en mede dankzij dit draadje weet ik nu ook de oorzaak.

We wachten dus even rustig af.