Als ik die zin zo lees, zeg ik ja. Er staat 64-Bit
En als ik zo die dump probeer te lezen, zie ik dat hij roept over een LinearRing die niet closed is.
Lijkt erop dat er een area wordt gedownload, die niet gesloten is.
Bij mij staat hij hier: W7 64 bit
C:\Users{naam}\AppData*Local*\JOSM\cache
C:\Users{naam}\AppData*Roaming*\JOSM
daar staat de:
preference.xml
preferences.xml_backup
Ben er uit: !!!
Nadat ik wederom schoon begonnen ben met een nieuwe preference.xml ging de BAG download goed.
Daarna mijn eigen preferende.xml en liep weer vast.
Heb toen de plugin bekeken, welke gedeelde plugins er gebruikt worden: osdbag requires opendataservice die op zijn beurt geotools en die weer jts, wel een gezamelijke plugin importimageplugin, enable maar dat was het niet.
Toen viel mijn oog op de plugin proj4j met coordinaatstelcils, uitgezet en voila bagdata wordt opgehaald, aangezet loopt vast. 
Gebruikte deze om te kijken of je bepaalde wms layers aan de gang kon krijgen, dacht dat het werkte, dus ik heb hem laten staan.
Dus GERTJAN die proj4j plugin is de boosdoener.
Dan zal de odsbag aanvraag aan de wfsserver, wel een aanvraag in het verkeerd stelcil zijn en krijg je niks terug.
Of er wordt een automatisch omzet proces op gang gezet.
Zou niet zo mogen zijn dat andere plugins invloed hebben op jouw plugin.
Ach: wat heeft dit al een irritatie opgeleverd. Je gaat er van alles bij verzinnen, verkeerde scanners op zo.
Bij het teken van polygonen gebieden bag geef ik de upload=false
Sommige data is zo correct geplaatst.
Mag ik de Bagpanden daar ook onder plaatsen?
Dan zou ik willen dat deze niet verschoven kunnen worden.
Nu zie ik nodes die veplaatst worden, een reden is het koppelen van de omgeving aansluitend aan het bagpand
Wanneer er op de nodes en polygon van het bag gebouw de tag **move=false **zou staan.
Zou het dan mogelijk zijn dat alleen maar het omliggende gekoppeld worden aan het Bagpand. Deleten Bag gebouw kan, verschuiven baggebouw als alleen maar move=false verwijdet wordt.
Zonder dat de Bagnode verschuift. Is dan een vorm van protection.
Zal vast een JOSM kwestie zijn.
Wat vinden jullie?
http://www.openstreetmap.org/note/342743#map=19/52.72195/6.08142&layers=N
Men zet een note bij 1 dat 1a mist. (verkeerde plaats), ik zou hem daar ook verwachten.
Daar ging ik de mist in, blijkt dat 1a wel al in de bag staat, gebouw Zeilmakerij Boer.
Men ziet op de kaart geen 1a staan, dus dat is een fout, denkt men.
Dat is dus het nadeel als de adresnode, naar het pand verplaatst wordt. En niet meer zichtbaar is.
Helaas is de BAG data niet altijd even betrouwbaar.
Wel een leuk voorbeeld, het heeft namelijk een eigen BAG referentie, ook de start_date is in alle 3 gevallen anders.
Toch is het een overlapping, importfout, BAG-data vertaalslag.
Kleinste BAG gebouw:
building=yes
ref:bag=119100000018483
source:date=2014-02-11
source=BAG
start_date=1989
building=yes
ref:bag=119100000009092
source:date=2014-02-11
source=BAG
start_date=1993
building=yes
ref:bag=119100000000692
source:date=2014-02-11
source=BAG
start_date=1925
Commodoortje, ja das leuk dat is dus de rechstreekse import. Maar nu de oplossing, logisch losmaken, met een corrupt beeld als gevolg of melden bij de beheerder ? En wachten op de volgende BAG update ?
Hier ik bag alleen binnen mijn Gemeentegrens.
en als je de bag (wfs) hier bij dit gebouw ophaalt, zie aan de andere kant van de grens, twee driehoekjes bij de andere gemeente met eigen baqref.
Dus alleen controle van eigen crossing buildings en niet met de buurgemeenten.
De laatste week met een aantal Gemeenten contact gehad.
In 2014 toen wij bezig waren stonden er nog veel fouten in, te veel om te melden. Maar nu,…
Ik had een pand, wat in 2014 opnieuw gebouwd is en al op luchtfoto 2014 staat, maar niet in de Bag.
Dit was van een afnemende Gemeente, van stichting GBKN ½ jaarlijkse controle, kadaster inmeten, dan wordt er door de Gemeente nog ½jaarlijks een update gedaan, ben je dus meer als een jaar onderweg voordat het in de BAG staat.
Bij een andere Gemeente, als test, een stel JOSM BAG validatie wfs meldingen doorgegeven, alle bleken niet goed, inzoomen minuscuul foutjes, maar toch fouten, hun controlesysteem had deze er niet uitgehaald, dat verwonderde hun, omdat het fouten waren die er al jaren staan en zullen actie ondernemen. Naar hun tekende partij.
Dit hoeft niet altijd een probleem in de BAG data te zijn. Het kan ook door de import komen.
In de BAG is ieder pand een los object. In OSM delen buurpanden elkaars nodes. Bij de import moet er daarom een vertaalslag gemaakt worden om de panden ‘aan elkaar te knopen’. Dit gaat meestal goed, maar een enkel keertje ook niet. Bij minuscule foutjes (< 10cm ?) moet je dus de geometrie in Josm aanpassen en niet terugmelden aan de gemeente.
Een beter algorithme om de panden op elkaar aan te sluiten is natuurlijk ook welkom, maar neem van me aan dat dat een behoorlijke kluif is.
Gertjan, moeten volgens die redenatie dan al die uitstekende spouwmuren worden aangepast ? http://www.openstreetmap.org/#map=19/52.46884/4.84684 of een duidelijker voorbeeld, http://www.openstreetmap.org/#map=19/52.66509/4.83369 pand 13 - 11. Waar de scheidingsmuur wordt toebedeeld aan beide panden. Juridisch juist en daarom toch laten staan, maar 't ziet er IMHO niet uit.
Ik heb ook aangegeven mogelijke fouten, ze reageerde terug dat in hun data ook de fouten bestonden.
Deze “spouwmuren” hoeven zeker niet te worden aangepast. Zo is de BAG data in dit/deze gevallen.
De fouten die ontstaan of aanwezig zijn in de BAG, dienen opgeloste te zijn voor de upload plaats vindt. Zoals in de BAG handleiding beschreven onder STAP 2 G.
Goed punt. Die werd in het begin van de import toegepast om gebouwen die wel in 3dShapes stonden maar niet in de BAG te behouden. Later is een meer verfijnde tagging toegepast. Eigenlijk zou bij al deze gebouwen de verfijnde tagging nog toegepast moeten worden waarnaa bag=conversie op zo’n gebouw verwijderd kan worden.
Uit de handleiding voor de import:
“Sommige gebouwen staan wel in 3dShapes, maar niet in de BAG. Die gebouwen willen we behouden. Doorzoek daarom in de laag OSM BAG handmatig industriële complexen op aanwezige opslagtanks, volkstuinen, bunkers en sportcomplexen (tribunes). Opslagtanks kun je vinden met het geïnverteerde filter ‘nodes:20- building’. Voeg bij opslagtanks de tag man_made=storage_tank toe, bij bunkers building=bunker en bij volkstuintjes building=shed. Volkstuinen herken je aan landuse=allotments, industriële complexen aan landuse=Industrial”
Wat houdt die verfijnde tagging precies in? Kunnen we niet gewoon al die bag=conversie verwijderen dan?
Even OT: Ik wilde deze post snel na een eerdere post plaatsen maar dat lukte niet.
At least 120 seconds have to pass between posts. Please wait a little while and try posting again.
Zal wel te maken hebben met al die spam die in andere onderdelen van dit forum geplaatst wordt.
Het zou jammer zijn om bag=conversie te verwijderen voordat de verfijnde tagging is toegepast, omdat door de verfijnde tagging aan objecten een betekenis is te hangen.
Concreet houdt die verfijnde tagging in:
- building=shed voor huisjes in volkstuinen
- building=bunker voor de objecten waarvan men ooit dacht dat ze bescherming boden tegen kanonnen
- man_made=storage_tank voor olie-, water- en andersoortige opslagtanks
OK. Helder. Ik dacht even dat er naast dit rijtje tagging nog iets moest gebeuren. Ik zal eens kijken of deze tags er al op zitten en dan de converisie verwijderen.
Behalve bunkers (de peellinie) zijn ook (kleine?) oude gebouwen verdwenen na de bag import.
Met name wegkappellen heb ik paar keer toegevoegd.
Is er een mogelijkheid om de oude 3dshapes gebouwen als overlay in josm te zien om de bunkers langs het peelkanaal opnieuw in te voeren?