Idee om wat met BAG te gaan doen

Communities Nederland (Netherlands)
921

We staan op de frontpage van de wiki met de IOTW !!!
http://wiki.openstreetmap.org/wiki/Main_Page

edit: Net 9 seconden te laat…

922

Proficiat mensen, de heer Ramm moet wel erg sterk in zijn schoenen staan wil die dit project de nek omdraaien :wink:

923

Ik heb het bericht, inclusief het idee van Harry over de kwaliteitsverbetering (wel in iets andere bewoordingen), zojuist verstuurd aan de importlist en de DWG: https://lists.openstreetmap.org/pipermail/imports/2014-May/003169.html

924

+1
Netjes verwoord.

925

Voor het geval je al die links niet wilt volgen. Blijkbaar is het in Afrika minder erg als je “source” en “source:date” op alle ways zet. Na de eerste vraag of ze wel nodig zijn, blijft het stil vanuit de waakhonden en de imports gaan gewoon verder.

926

Er is weer een verse BAG: 2014-05-20.

927

ik ben een beetje raar probleem tegen gekomen. als ik een bepaald gebied probeer te downloaden krijg ik de volgende error:

Er trad een onverwachte exceptie op die mogelijk afkomstig van de plug-in "opendataservices". Volgens de informatie in de plug-in, is de auteur Gertjan Idema  . Probeer eerst de plug-in bij te werken naar de nieuwste versie voordat u een fout rapporteert.

opnieuw proberen helpt niet.

het gebied bevindt zich hier: http://www.openstreetmap.org/#map=14/51.3999/5.9005
en dit is de polygon:

<?xml version='1.0' encoding='UTF-8'?>
<osm version='0.6' upload='true' generator='JOSM'>
  <node id='-132691' visible='true' lat='51.404715162745205' lon='5.896739382298612' />
  <node id='-132690' visible='true' lat='51.41011275652915' lon='5.903635586154556' />
  <node id='-132689' visible='true' lat='51.41139' lon='5.907846' />
  <node id='-132688' visible='true' lat='51.4075' lon='5.911532' />
  <node id='-132687' visible='true' lat='51.40482' lon='5.913931' />
  <node id='-132686' visible='true' lat='51.40361208536417' lon='5.915164965769215' />
  <node id='-132685' visible='true' lat='51.40295' lon='5.915633' />
  <node id='-132684' visible='true' lat='51.40218' lon='5.916571' />
  <node id='-132683' visible='true' lat='51.40146' lon='5.916911' />
  <node id='-132682' visible='true' lat='51.39938' lon='5.918674' />
  <node id='-132681' visible='true' lat='51.39751' lon='5.920381' />
  <node id='-132680' visible='true' lat='51.39576' lon='5.921836' />
  <node id='-132679' visible='true' lat='51.39416' lon='5.923217' />
  <node id='-132678' visible='true' lat='51.39203' lon='5.925083' />
  <node id='-132677' visible='true' lat='51.39055' lon='5.926294' />
  <node id='-132676' visible='true' lat='51.3874704756184' lon='5.914851673483078' />
  <node id='-132675' visible='true' lat='51.387853446569196' lon='5.912919741450854' />
  <node id='-132674' visible='true' lat='51.388162326908954' lon='5.911868304137339' />
  <way id='-132673' action='modify' visible='true'>
    <nd ref='-132674' />
    <nd ref='-132675' />
    <nd ref='-132676' />
    <nd ref='-132677' />
    <nd ref='-132678' />
    <nd ref='-132679' />
    <nd ref='-132680' />
    <nd ref='-132681' />
    <nd ref='-132682' />
    <nd ref='-132683' />
    <nd ref='-132684' />
    <nd ref='-132685' />
    <nd ref='-132686' />
    <nd ref='-132687' />
    <nd ref='-132688' />
    <nd ref='-132689' />
    <nd ref='-132690' />
    <nd ref='-132691' />
    <nd ref='-132674' />
  </way>
</osm>

de polygon was eerst groter, maar ik heb hem een paar keer kunnen splitsen en de andere helft wel gewoon kunnen downloaden. mijn vermoeden is daarom dat er in het overgebleven stuk een object zit dat het probleem veroorzaakt. Ik heb ook van het hele gebied de OSM-data gedownload en door de validator gehaald, maar dat hielp niks.

928

Net iets te weinig informatie om te weten wat je hiermee wil zeggen :wink:

Heb je alleen de polygon aangepast en het daarna opnieuw geprobeerd?
Heb je de plugin disabled en daarna enabled via het menu?
Heb je JOSM helemaal opnieuw gestart?

Mijn ervaring is dat JOSM het soms niet snapt als je de laatste keer JOSM hebt afgesloten terwijl de plugin nog enabled was. JOSM opnieuw starten helpt dan.

929

ik heb alle mogelijk combinaties van bovenstaande geprobeerd, niks helpt.

ik krijg die foutmelding vaker, maar een tweede en heel soms een derde keer proberen normaal werkt altijd

930

de Vries, ik had hetzelfde probleem. Bij mij hielp het om een nieuwe polygons.poly aan te maken in de map van de plug-in. Daarna werkt bij mij alles weer naar behoren.

931

zeg nearo, was dat toevallig toen je naast de desbetreffende polygon aan het werk was? De oostgrens ervan heb ik nl. van jou polygon gekopieerd. het lijkt me onwaarschijnlijk, maar de gedachte dat het misschien komt door dat er iets raars met jou poligonen aan de hand is wel bij me opgekomen.

ik werk overigens met .osm bestanden die ik niet in de plugin map heb staan, maar ik heb al wel geprobeerd om de polygon naar een nieuwe laag te kopiëren. Andere polygonen werken overigens wel.

Edit:
Ik zie nu dat de nodes in mijn .osm bestand niet allemeel met hetzelfde aantal decimalen staan beschreven:

<node id='-132677' visible='true' lat='51.39055' lon='5.926294' /> 
<node id='-132676' visible='true' lat='51.3874704756184' lon='5.914851673483078' />

Edit 2:
de coordinaten met 5 decimalen heb ik van Nearo overgenomen, maar bij eerdere polygonen is dit ook goed gegaan.

932

Het heeft volgens mij niets met de precisie te maken. Ik heb al veel verschillen gezien.
Wat je eens zou kunnen proberen is om je osm op te slaan als poly en dan diezelfde poly in te lezen: Heb je dan nog hetzelfde aantal polygonen? Zitten er misschien niet-gesloten polygonen in je osm? Zit er “niet polygon” data in je osm?

933

Dan heb ik inderdaad 1 object minder. de polygon in kwestie is gewoon gesloten.

edit: als ik die ene poly opsla (.osm) is het 1 weg (duh) als ik dit omzet naar een .poly nog steeds.

edit2: oorzaak gevonden; er stond ergens een weg van 2 nodes in mijn polygon.osm bestand. dit is niet gerelateerd aan het probleem.

934

Ik wil iedereen er nog even aan herinneren dat de laatste stap van het import-proces is om de Steet-not-found problemen die OSM Inspector vindt op te lossen. Het valt me op dat een groot deel van Nederland nog veel fouten bevat. Het is een erg nuttige stap - misschien wel de meest nuttige stap van het hele proces - want het zorgt er (onder andere) voor dat we alle missende (bewoonde) straten (voornamelijk in nieuwbouwwijken) toevoegen.

935

Die OSM inspector is inderdaad errug nuttig. Door de rode markeringen vind ik soms ook BAG adressen met inconsequent gespelde straatnamen door de gemeente.

En als je beter kijkt naar groen gemarkeerde wegen zie je soms veel te lange connecties naar adressen. Dan blijkt een straat sinds de AND import niet gewijzigd te zijn en deels geen of de verkeerde naam te hebben.

Je komt ook verwarrende situaties tegen waarbij je OSM inspector niet groen krijgt. Voorbeeld: http://www.openstreetmap.org/#map=19/51.91895/5.11666:
Straat op woonplaatsgrens met aan beide zijden nummer 1. Noordkant heeft als BAG-adres “Kerkweg 1, Schoonrewoerd”, Zuidkant heeft BAG-adres “Schoonrewoerdse Kerkweg 1, Leerdam”. Straatnaambordjes aan beide zijden tonen “Kerkweg” dus die heb ik ook gebruikt in OSM.

936

De nieuwste versie van de CartoCSS stylesheet, die wordt gebruikt op www.openstreetmap.org, is zojuist uitgerold. Tiles worden gecacht, dus hat kan even duren voor je de nieuwe tiles ziet.

In deze versie wordt building=house etc. niet meer lichter gerenderd dan building=yes.

Ik had ook beloofd te zorgen dat covered=yes en tunnel=building_passage gerenderd zouden worden (als tunnel), maar daar gaat nog iets mee mis. Dat wordt meegenomen in de volgende versie.

Als er verder nog wensen zijn, laat het me dan weten - hier in het topic als het BAG-import gerelateerd is, of anders op de issue tracker op Github: https://github.com/gravitystorm/openstreetmap-carto/

937

Inderdaad @ruudblank. Errug nuttig. Sommige straatnamen ontbreken. Hele straten ontbreken zelfs. Bij gemeentegrenzen verandert vaak de straatnaam. De verkeerde straatnaam loopt vaak nog kilometers door in een aangrenzende gemeente. enz enz enz. Ik heb soms meer werk aan osm inspectorfouten herstellen dan aan BAG importeren.

René.

938

Fijn. Alleen jammer van die tunnel=building_passage. We wachten af (ook namens Gemeentehuiis Ede :slight_smile: ).
Meestal valt het niet zo op, maar die combinatie van wegentype, tweemaal eenrichting en een brugconstructie voor het gemeentehuis pakt hier ongelukkig uit.

Omdat de BAG ons nu in staat stelt om ook nog ondergrondse gebouwen in OSM te zetten, is daar een andere rendering voor te verzinnen? (Alleen een gestippelde outline, zoals ook voor tunnel e.d. zou fijn zijn. Anders lijkt er in OSM een pad te lopen door een gebouw (zoals hier besproken).

939

Ja, erg vervelend, de huidige rendering. Het staat in elk geval op de planning…

Goed punt. Wat is de standaard tagging? Is een negatieve layer voldoende om aan te nemen dat het om een ondergronds gebouw gaat? Ik ben bang dat we ook bovengrondse gebouwen met negatieve layertags in de database hebben staan. Een gestippelde outline lijkt me inderdaad een oplossing voor de rendering. Ik heb een ticket aangemaakt op Github.

940

Ik zou gaan voor location=underground. Maar ik heb ook layer=-1 er op gezet. Beide tags ondersteunen lijkt me nog beter.
Location: http://wiki.openstreetmap.org/wiki/Key:location

Ik heb ook 3D tags er op gedaan (en dat werkt inderdaad in tenminste een van de 3D-renderers).