Data stapelingen

De laatste tijd is me opgevallen dat - na de BAG import - op veel gebouwen en objecten meerdere sets van data van toepassing blijken te zijn. Soms tegenstrijdig, soms volkomen overbodig omdat beide sets gelijk zijn. Dat leidt er bv.toe dat op de OFM een gebouw soms een enorme lijst van attributen krijgt die nergens op slaan. Geen fout van OFM, maar een fout van OSM.
Het probleem lijkt te zijn dat bij een grote import van gegevens niet (altijd) wordt gecontroleerd wat er al staat en of dat elkaar niet uitsluit.

Soms is ook niet duidelijk waar je bepaalde attributen aan moet koppelen.

Kijk bv.eens hier:

http://www.openstreetmap.org/way/272337616

Dat gebouw heet “Rozenoord” en dat is een historische naam die zelfs in de gevel is vastgelegd. Het lijkt me duidelijk dat ik in dit geval die naam ook echt aan het gebouw koppel. Dat heb ik dan ook gedaan. In dat gebouw echter zetelt ook een stichting ABZ, die zich met kunstzinnige vorming bezighoudt. Die stichting kan er morgen weer uit zijn, en dus heb ik die stichting er dmv. een losse node bovenop gezet.
Correct?

En dan hier:

http://www.openstreetmap.org/way/294472686

Het gaat hier om een school.
Moet je de naam van de school aan het gebouw koppelen?
In dit geval heb ik dat niet gedaan, omdat de school uit meerdere gebouwen bestaat (waarvan er overigens maar 1 in de BAG voorkomt) en ik niet ieder van die gebouwen met die naam wilde taggen, want dan zouden er ineens 3 gelijknamige scholen vlak bij elkaar liggen.
Ik heb er dus voor gekozen om het hek dat om het hele schoolcomplex staat als begrenzing van het schoolgebied te nemen en daar de naam (Maurick College) aan vast te zetten.
Correct?

En dan hier:
http://www.openstreetmap.org/way/272337028
Volgens mij heb ik het hier verkeerd gedaan, want ik heb aan het gebouw ook de functie (retail) gekoppeld, en dat kan ook morgen weer over zijn, maar dat gebouw kan er over 100 jaar nog staan.
Dus hier zou ik die functie onder moeten brengen in een losse node.
Correct?

De BAG beschrijft volgens mij de locatie (coordinaten) en de administratieve gegevens van een gebouw, maar niet de functie. Althans niet heel gedetailleerd (iets kan een winkelpand zijn, maar in de BAG staat volgens mij niet dat er een drankhandel is gehuisvest).
Correct?

Ik kom op deze waarnemingen na recent met nogal wat tegenstrijdigheden in aanraking te zijn gekomen. (Zie mijn posts over de kerken).
Bovendien valt me ook op dat mappers in verschillende landen er totaal andere ideeën op na houden over wat wel/niet moet/kan.
Ik map en ben veel in Spanje, en in Andalucia (dat 2x groter is dan Nederland) heb ik meer gemapt sinds 2012 dan in Nederland sinds die tijd, en ik moet daar totaal andere problemen oplossen dan hier.
Kortom, OSM heeft nog een lange weg te gaan als het een uniform hulpmiddel wil zijn.
Hier ligt misschien ook wel de oorazak van de recente storm die in de Openstreetmap Foundation losbarste en die zeker nog wel even aan zal houden todat het nieuwe bestuur duidelijk maakt waar het voor staat.

Een echt hard correct of fout kan ik je niet geven, want met het open data model van OSM, kan iedereen doen wat hij / zij wil. Desondanks kan ik mij in deze redenatie goed vinden, ik denk dat dit een redelijke oplossing is, zeker als je bedenkt dat dergelijke panden vaak meerdere functies / bedrijven / stichtingen bevatten.

In de Wiki wordt duidelijk ook gesproken over de mogelijkheid om het gehele terrein te taggen met de school / college / universiteitsnaam, i.p.v. individuele gebouwen. Dus ik denk dat dit OK is.

Met deze ben ik het niet eens. Op zich heb je gelijk dat de retail functie kan vervallen, maar desondanks blijft deze toch vaak veel langer behouden dan je denkt, het is niet altijd makkelijk, noch logisch in een stadscentrum, om een winkelpand naar een andere functie te converteren (uitgezonderd de historische “voorkamer” winkeltjes in veel oude kleine stads-, dorpscentra). De winkel / retailfunctie blijft dan ook vaak behouden, hoewel de winkeleigenaar en het winkeltype continue kan wisselen.

Ik zie de “retail” functie dus als wel redelijk bestendig. Mede een reden waarom ik deze WEL, maar de exacte winkelnaam en -soort NIET, in mijn OSM Renderer for ArcGIS toon. Soms zit er bijna om het jaar een nieuwe winkel in hetzelfde “retail” pand…

Ik heb dat ook wel overwogen - en ben er ook nog niet helemaal uit - want voor veel soorten gebouwen (kerken, theaters, stadions enz) is het zo dat inderdaad die functie redelijk lang blijft bestaan. Een stadion zal inderdaad niet snel een bibliotheek worden, maar waarom zou het Feyenoordstadion niet gewoon het Ajaxstadion kunnen worden? :laughing:
Dus dat pleit ervoor om de functie wel op te nemen, maar de details zoals jij die beschrijft, niet.

Corrigeer me als ik het verkeerd heb, dat het beter is om alle tags op de pandcontouren te plaatsen (CTRL+SHIFT+G) + utilities plugin 2

Natuurlijk krijg je dan een stapeling van data op het pandcontour te staan, dit is ook juist de bedoeling. Zo kan een renderer gebruik maken van de info die in dat pand aanwezig is.
Het wordt natuurlijk anders als een pand meerdere adresnodes heeft, dan voeg ik de tags toe aan de adresnode waar het betrekking op heeft.

Als er dan een ander in het pand intrekt, omdat de vorige bijvoorbeeld gestopt is wegens rijkdom… zou je natuurlijk alleen de tags moeten verwijderen die niet meer van toepassing zijn, en tags toevoegen die op dat moment van toepassing zijn geworden.

Je kunt je een voorstelling maken dat een pand met 1 adres een winkelfunctie heeft, maar het pand is ook een rijksmonument, tevens zit het postkantoor erin.
Alle tags zet ik dan op het pandcontour, behalve de postkantoorfuntie, deze plaats ik op een nieuwe losse node. Meer omdat de tag shop=* dan al gebruikt is.
Wel plaats ik dan (meestal) een node op de plek waar de ingang zit van het pand. (entrance=main)

Ik zie namelijk vaak veel losse nodes shop=* + name=*, terwijl deze vaak samengevoegd zouden kunnen worden in mijn inzicht.
Graag zou ik kritiek willen ontvangen om de gedachte beter te kunnen vormen wat de logica eigenlijk is.

Ik laat hier nog even zien wat (voor mij) storend is:

Dit is de OSM kaart van de Heilig Hartkerk in Vught
http://www.openstreetmap.org/#map=19/51.65379/5.28690

Hier is de detailkaart
http://www.openstreetmap.org/way/272308879

Hieronder 4 afbeeldingen van wat ik zie op de OFM-kaart van @ligfietser, zoals ik dat te zien krijg in Basecamp en op mijn GPSmap62st.
Ik kan op 4 verschillende manier over de kerk informatie krijgen:


Op de standaardrendering van OSM staat de naam maar één keer, maar op OFM zie ik de naam al twee keer staan.
Daarnaast laat de tekstballon die tevoorschijn komt als ik de cursor op die plaats zet, ook steeds weer dubbele informatie zien.
Bij alle kerken die ik de laatste tijd heb bezocht (op de kaart :slight_smile: ), zien we ook steeds die (overbodige?) torenvermelding.

De oplossing van:

lijkt in dit geval wat rust in het kaartbeeld te brengen.
Maar er zijn vast nog meer oplossingen - die dan vast weer andere problemen oproepen.
In bovenstaand geval hebben we ook nog te maken met de keuzen van @ligfietser die hij moet maken als hij zijn kaarten rendert.

Lastig blijft natuurlijk dat de afspraken die we erover (zouden kunnen) maken, onmogelijk dwingend kunnen worden voorgeschreven, daarvoor is de structuur van de hele OSM samenleving veel te chaotisch. En dat is iets waar bv. de OSMF wat aan zou moeten doen met het gedeeltelijk vernieuwde bestuur.

Wie praat/denkt er nog meer mee?

Er zijn een aantal opties voor een rustiger kaartbeeld.
-Je kan de OFM typ file aanpassen, bv alle name tags uitzetten/onzichtbaar laten renderen. Dat doe ik niet want ik heb er geen last van. :wink:
-Dubbele tags op pois én gebouwen voorkomen.
-Onzinnige torendumps verwijderen

Hier een voorbeeld dat inderdaad makkelijk verkeerd kan worden getagd, gebouw “Het Kwartier”:

http://www.openstreetmap.org/#map=19/51.66677/5.27852

Hier een plaatje vanuit de iD-editor:

Let op: de onderliggende luchtfoto is niet juist. De contouren van de gebouwen zijn ook nog niet afkomstig uit de BAG maar gebaseerd op GPS waarnemingen en observaties ter plaatse.

Het is één gebouw dat de naam “Het Kwartier” heeft. In dat gebouw zit een basisschool “De Koningslinde”.
Tenslotte is ook nog een deel van het gebouw een turnhal van het nabijgelegen atletiekcentrum.
Ik ben benieuwd hoe de BAG straks dat gebouw neerzet, want het oogt (architectonisch) als één gebouw, maar er is geen verbinding binnendoor van de turnhal naar de basischool.

Ik heb dus twee gebouwen gemaakt en die elk een naam gegeven, maar feitelijk heten die twee gebouwen aan elkaar dus “Het Kwartier”. Die naam staat niet op de foto omdat hij onderdeel is van alle tags van dat gebouw.
Tenslotte heb ik de school als een losse node op het gebouw gezet, met de bedoeling, als straks de BAG import compleet is, om dan de naam van de school aan de adresnode te koppelen.
Is dat een bruikbare oplossing?

Dat wordt een levenswerk…

Ik was laatst aan het kijken hoe een bordje op het huis nu wordt genoemd. (Nu weet ik niet meer waar ik het op een huis gezet heb :laughing: en hoe getagd.)
Toen heb ik een paar overpass styles gemaakt.
http://overpass-turbo.eu/s/67b
http://overpass-turbo.eu/s/67e

Is maar net van uit welk hoek je het bekijkt.
Als er iemand een kaart wil maken met adresnummers erop en een POI voor de school, kan het zomaar zijn dat het renderende poisymbool bovenop de huisnummersymbool/nummer komt te staan, of omgekeerd.
Moet je dan een activiteit op het adrespunt zetten? of op een losse node? Bruikbaarder? Welke trucks moet de render uit halen om het ene symbool links van de node en de andere rechts van de node te zetten. Zodat je beide ziet.
En hoe koppel je de adress node aan dat ene punt.
Nu Nederland onder de huisnummers zit is het wel lekker als de huisnummers zichtbaar zijn op een kaart. Wat zichtbaar is kan je kontroleren.

addr:housename=… en name=… worden ook vaak tezamen toegepast met dezelfde naam =*

Ik neig steeds meer naar losse poi’s, vanwege simpele rendering, wat veelal wordt toegepast. Dat advies heb ik al eerder gehad.

Turnhal, hal daar komen misschien ook verschillende poi in, turnhal wordt soms ook volleybal gespeelt vollebaypoi, of is het echt alleen turnen?

Je kan alles op een element zetten, maar hoe moeilijk is het om het uit elkaar te trekken. en dat met de openingstijden voor de verschillende activiteiten.

Je hebt ook van die overlopende dubbelfuncties, restaurant, eetcafe, bar, muziek, keuken sluit om X uur, bar sluit om Y uur, na middennacht. Door de week bestaat er nog de mogelijkheid van biljart en dart en die zijn van Z uur tot V uur te gebruiken. Darten is van vrij voor customer, behalve op dinsdagavond, want speelt de plaatselijke dartvereniging. Het gebouw bestaat uit meerdere bag gebouwen. En is een historisch pand aan een kant.

Kindercreche in de voetbalkantine “het hobbelpaard” (commerciële activiteit) en op vrijdagavond is het de thuisbasis voor de jeugdvereniging “juist nu”, die vaak lezingen houden en buitenstaanders uitnodigen, in het gebouw “de hooiberg”.

Net even met de BAG plugin gekeken en de gebouwen liggen volgens BAG nog los van elkaar. Maar de status is in BAG dan ook nog “Pand in gebruik (niet ingemeten)”. Wellicht dat na inmeting de gebouwen nog naar elkaar toe schuiven.
Als je wilt kan ook de huidige pandcontour in OSM gezet worden inclusief de 4 adresnodes (1A-1D) die nu ontbreken.

Verbinding tussendoor is niet nodig voor BAG om gebouwen tegen elkaar te plakken. Hele woonwijken zitten tegen elkaar gebouwd zonder dat je binnendoor naar de buren kan.

Om de gebouwen als 1 geheel de naam “Het Kwartier” te geven kun je een multipoly gebruiken om dubbel taggen te voorkomen, al rendert dat lang niet altijd naar behoren.

Je hebt nu de node van de school de tag building gegeven. Dat lijkt me dubbel taggen. Ik zou de gebouwcontour building=school maken en de node amenity=school.

Voor sanders post had ik ook al even in de bagviewer gekeken http://bagviewer.geodan.nl/index.html.

Daar staan inderdaad twee gebouwen met status ‘Pand in gebruik (niet ingemeten)’ in die er behoorlijk anders uitzien. De turnhal bevat één verblijfsobject met een bijeenkomstfunctie, Adres: Koninginnelaan 1 D. Het schoolgebouw bevat een verblijfsobject met een bijeenkomstfunctie (1 A) en twee verblijfsobjecten met een onderwijsfunctie (1 B en 1 C). Volgens de BAG zit er dus zelfs meer dan één school in dat gebouw. Dat stukje weg heet waarschijnlijk Koniginnelaan en niet Willem de Rijke laan ik zou de BAG tags op de gebouwen van marc zetten en de nodes importeren. Die school zit in 1b http://www.obsdekoningslinde.nl/contact

Verder lijkt het me die torendump niet compleet onzinnig, dat torensymbooltje op de kerk in de rendering van ligfietser voegt mijns inziens wel degelijk wat toe. De hoeveelheid tags is misschien een beetje overdreven maar dat het uit de officiële topografische kaart komt vindt ik dan wel weer nuttig om te weten. Het blijven oriëntatiepunten.

Groeten Simon

Google weet raad, in 1a zit een kinderopvang/peuterspeelzaal/BSO
https://www.partou.nl/kinderopvang-noord-brabant/vught/stadhouderspark/koninginnelaan
en in 1c nog een andere school:
http://portal.leijestroom.nl/scholen/HetMolenven/Paginas/Contact.aspx

Dat brengt direct weer het probleem met een globale uniforme regel voor OSM aan het licht:

Een kennis van ons woont in Ierland en haar huis heeft geen huisnummer.
Je stuurt een brief aan haar naar het dorp waar ze woont en die komt op het postkantoor terecht in het vakje “de vrouw die woont naast het huis van haar broer die hier al 15 jaar woont”. Gaat altijd goed!
Tagging suggesties?

Met andere woorden, wat wij hier uitdenken werkt bij onze buren misschien wel helemaal niet…

Nee, dit is echt alleen maar een turnhal.

Je geeft nog meer voorbeelden van zaken die we kunnen taggen, maar moeten we dat wel willen?

[overwegingen aan]
Ik kwam gisteren tijdens een wandeling op een pad terecht dat voor 50 procent bestond uit grote modderpoelen en waterplassen.
Het is niet moelijk om die te taggen, daar is vast wel iets voor te verzinnen. Als ik dat had kunnen zien, dan had ik andere schoenen aan kunnen trekken.
En met de software die over 5 jaar op de markt is, zal het in realtime doorgevoerd kunnen worden (binnen 5 milliseconden) op alle OSM kaarten op alle apparaten in de hele wereld. Maar hoe goed en snel we het ook maken, steeds weer is er een nieuwe grens die we willen (en kunnen!) doorbreken.

Het lastige (vind ik) is dat je een kaart probeert te maken die je optimaal vindt (voor mij is dat een kaart waar alle wegen op staan waar ik op kan fietsen/wandelen), maar voor een ander zijn alleen de autowegen van belang waar je 180km/u kunt rijden.

Wat we nodig hebben is software die heel eenvoudig is te configureren naar onze eigen, persoonlijke kaartvoorkeur (kleuren, symbolen enz), en die we kunnen voeden met de data uit OSM. Maar dat bestaat nog niet. Ik gebruik nu de voorkeuren van OFM, Velomap en Freizeitkarte. Voor mij is Freizeitkarte het handigste, want als ik nu iets verander in de kaart, kan ik zelf een nieuwe kaart compileren en in mijn Garmin stoppen. Kost me ongeveer een halfuur. Maar ik heb eigenlijk liever het kaartbeeld van OFM. Waarom kan ik dat niet gewoon gebruiken. (Ik heb geprobeerd de stylesheets te kopiëren, maar dat ziet er echt niet uit…)
Maar bij Velomap en OFM moet ik een week wachten…
[overwegingen uit]

Dat had ik ook al gezien, en is inderdaad onlogisch. Dat ga ik veranderen.

Grappig is dat, deze situatie uit de BAGviewer (zie onder) komt inderdaad niet overeeen met de werkelijkheid!
Ik ga morgen wel even kijken hoe die straat heet, want dat is onduidelijk.

Volgens de BAG is dat “Koninginnelaan”. Op het BAG kaartje, kun je op het pand klikken, dan verschijnt deze informatie aan de rechterzijde.
Straatnaam is ook te achterhalen via de PDOK viewer (http://pdokviewer.pdok.nl/) en dan bij lagen kiezen voor Nationeel Wegen Bestand - Wegen - Wegvakken. Dan nog even de i in het blauwe rondje klikken en bij het aanklikken van een wegvak verschijnt alle beschikbare informatie. Altijd handig als het morgen blijkt te stortregenen of zo :smiley: en/of de borden nog niet zijn geplaatst.

Op basis van het in de afgelopen 10 jaren ontwikkelde mantra ‘support but not control’ houdt OSMF zich niet bezig met de ontwikkeling van tagging conventies. Dat moet echt van discussies zoals deze afkomstig zijn die, op basis van goed luisteren naar elkaar, enige orde kunnen aanbrengen

Da’s eigenlijk best vlot. Bij TomTom duurt dat nog steeds 3 maanden :slight_smile:

Cheers, Johan

ik moest eerst even uitzoeken wat ik ermee kon doen, maar het is inderdaad een mooi hulpmiddel!

Het wordt inderdaad lastig als een gebouw een naam heeft, en daarin een “amenity” zit die ook een “andere” naam heeft - hier heeft de community niet een goede oplossing voor. Mijn idee zou zijn om iets als name:amenity=… naast name= of name:building= te maken.

Qua BAG: ook die kan er naast zitten. Zo heb je in Bunschoten-Spakenburg de Huijgenlaan. Alle gebouwen aan deze straat lagen volgens de BAG-viewer echter aan de Huygenlaan. Ik zie dat dit inmiddels is gecorrigeerd, wellicht dankzij mijn vraag aan de gemeente wat nou de correcte straatnaam is (ik werk bij Connexxion en wij wilden de haltenaam goed gespeld hebben).

http://overpass-turbo.eu/s/67z andere query
ik had hem nog niet gevonden.
maar nu wel met iets anders zoeken

een naam op een huis, moet dat getagd worden met
name=*
of met
addr:housename=*

omdat in Nederland een huisnaam (gebouwnaam) niet een onderdeel uit maakt van het adres vond ik “name” correct.

Dat zie ik vaker bij buildings grote gebouwen in NL
addr:housename=… en name=… worden ook vaak tezamen toegepast met dezelfde naam =* ik vraag met dus af of het gebruik van addr:housename wel correct is voor Nederland.

Als je een Freizeit kaart kan compileren kan je dat ook met de OFM doen. Ik neem aan dat je dat met mkgmap doet?
Zie verder http://forum.openstreetmap.org/viewtopic.php?id=27664