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:
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?
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.
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.
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.
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.
Fijn. Alleen jammer van die tunnel=building_passage. We wachten af (ook namens Gemeentehuiis Ede ).
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).
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.
Edit:
in het verleden heb ik ondergondse garages ook met building=garage getagd. ik geloof dat deze tag echter meer voor individuele garageboxen bedoeld is.
layer zegt echt niets over onder of boven de grond zelfs niet met negatieve waarden. Neem bijvoorbeeld iets dat in een kuil staat en gedeeltelijk overlapt met iets “naast” de kuil.
Ook een idee.
Als we de BAG-ligplaatsen gaan taggen met mooring, zou het helpen als Mapnik die zichtbaar maakt, bijvoorbeeld omtrek met een donker blauwe stippellijn, binnen transparant (omdat die grenzen soms ook liggen aan de wal, voor een tuintje, enz.).
Nu zijn ze onzichtbaar en tonen geen adres als ze geen building=houseboat meer zijn.
Zoals ze kennelijk in de BAG zijn vastgelegd, lijkt het me dat een straatadres behoort bij een ligplaats en niet bij een woonboot die eventueel kan vertrekken/verplaatst kan worden. De adrestags overzetten naar een (middels Bing_sat) ingetekend woonboot/-ark lijkt me dan ook onjuist. Maar doen alsof een ligplaats een gebouw is, is eveneens onbevredigend.
Hi, heeft hier iemand ooit gesignaleerd dat er met de BAG import en de verwijdering van de oude contouren ook de daaraan hangende geschiedenis verdwijnt ? Of zie ik het niet goed ?
Ik weet niet hoe de andere importeurs precies werken:
Als een gebouw alleen building=yes en de 3dShapes tags heeft dan gaat de geschiedenis inderdaad verloren (als het vervangen wordt. Zodra er meer tags op staan zou geschiedenis er nog moeten zijn, omdat ik “replace geometry” in JOSM gebruik. dan krijg je dus dit effect: https://www.openstreetmap.org/way/57931423/history
Als je nu uitgebreid gaat graven kun je vast wel gebouwen vinden die ik heb geïmporteerd waar je geschiedenis verwacht volgens bovenstaand statement, maar waar die niet is. Ik ben helaas ook maar een mens…
Hi Cartinus, ik keek na een reis door openbare archieven even naar mijn eigen werk en aanpassingen. De aangebrachte tags zijn wel overgenomen maar wie er ooit aan een pand gewerkt of aan bijgedragen heeft is met H in P2 niet meer te zien. Slechts de laatste BAG import komt in beeld. Je aanhef baart mij zorgen, dat houdt mogelijk in dat niet iedere Baggeraar dezelfde methode en werkwijze volgt. Zorgelijk ?
Ik heb even een aantal dagen niet gekeken dus ik loop misschien een beetje achter, maar als je de volledige validatie van JOSM pakt krijg je deze fouten er toch ook gelijk uit?
Ik heb al heel veel wegen aangepast die geen naam hebben, of “straten met gelijkluidende naam” (of iets dergelijks) waarmee je de harderwijkerstraat en hardewijkerstraat e.d. er uit krijgt.
Blijft op zich een feit dat de inspector stap wel degelijk gedraaid moet worden omdat ook JOSM wel eens iets mist en ook niet de inconsequentie aangeeft tussen “burg. huppeldepupstraat” en “burgemeester huppeldupstraat” op BAG panden en straten. Hoewel gemeentes, gemeentelijke stadsplattegronden, verschillende naambordjes in één straat, postcode.nl, openstreetmap, enz. enz. ook niet consequent zijn.
Waar de straatnaam volgens BAG verschilt met de schrijfwijze op de borden, wat doen we dan met de straatnaam op de weg? Het on-the-ground principe van OSM zegt dat je de straatnaamborden moet volgen boven een of andere officiële schrijfwijze, maar tegelijkertijd willen we de straatnaam van de adres-nodes overeen laten komen met de straatnaam op de way.
Is dit ergens besproken? Het lijkt me handig om dit even helder te krijgen voordat goedbedoelende mappers de straatnamen terug gaan zetten en de link verbreken met de adressen.
Is een verschil tussen het gemeentelijke straatnaambesluit en de BAG ook mogelijk? In dat geval is het zo vanzelfsprekend dat de BAG prevaleert?
).
Zorgelijk ?