Idee om wat met BAG te gaan doen

Ik heb vernomen dat een aantal mappers problemen hebben gehad met de BAG-plug-in.
Bij mij heeft de plug-in gewoon normaal gewerkt.
De oplossing die @Allroads aangeeft is bij JOSM problemen meestal de oplossing.
Je zou de map C:\Users{naam}\AppData\Roaming\JOSM\cache een andere naam (bijvoorbeeld cache1) kunnen geven, waardoor JOSM automatisch een nieuwe schone cache gaat opbouwen.

Wel moet je realiseren dat je al je gemaakte instellingen in JOSM dan kwijt bent.

Mocht je het echt niet meer weten rename je nieuwe cache directory naar bijvoorbeeld **cache2 **en zet je **cache1 **even terug.

Vaak doet het wonderen om even opnieuw te beginnen.

Josm opgestart met:


echo off
cls
java -jar -Xmx2048M "C:\Program Files (x86)\JOSM\josm-tested.jar"
pause

Stapgewijs:

Enable ODS

Layer mapnik en wms bag geopend.

Polygon getekend
Download osm data en bag data
Dan krijg ik als laatste stuk in het cmd venster ( na laatste stap)

Na op download drukken, processing en error opendataservices


INFO: GET https://api.openstreetmap.org/api/0.6/map?bbox=5.626412,52.6673406,5.6
275742,52.668442
Jul 01, 2015 6:10:19 PM org.geotools.xml.resolver.SchemaCache resolveLocation
INFO: Cached XML schema: http://geodata.nationaalgeoregister.nl/bag/wfs?service=
WFS&version=1.0.0&request=DescribeFeatureType&typeName=bag%3Astandplaats
ERROR: org.openstreetmap.josm.io.OsmTransferException: java.util.concurrent.Exec
utionException: An error occured while downloading the data:
java.lang.IllegalArgumentException: Points of LinearRing do not form a closed li
nestring. Cause: java.util.concurrent.ExecutionException: An error occured while
 downloading the data:
java.lang.IllegalArgumentException: Points of LinearRing do not form a closed li
nestring
org.openstreetmap.josm.io.OsmTransferException: java.util.concurrent.ExecutionEx
ception: An error occured while downloading the data:
java.lang.IllegalArgumentException: Points of LinearRing do not form a closed li
nestring
        at org.openstreetmap.josm.plugins.ods.OdsDownloadAction$DownloadTask.rea
lRun(OdsDownloadAction.java:134)
        at org.openstreetmap.josm.gui.PleaseWaitRunnable.doRealRun(PleaseWaitRun
nable.java:93)
        at org.openstreetmap.josm.gui.PleaseWaitRunnable.run(PleaseWaitRunnable.
java:161)
        at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
        at java.util.concurrent.FutureTask.run(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
Caused by: java.util.concurrent.ExecutionException: An error occured while downl
oading the data:
java.lang.IllegalArgumentException: Points of LinearRing do not form a closed li
nestring
        at org.openstreetmap.josm.plugins.ods.OdsDownloader.subTask(OdsDownloade
r.java:167)
        at org.openstreetmap.josm.plugins.ods.OdsDownloader.run(OdsDownloader.ja
va:70)
        at org.openstreetmap.josm.plugins.ods.OdsDownloadAction$DownloadTask.rea
lRun(OdsDownloadAction.java:132)
        ... 7 more
ERROR: org.openstreetmap.josm.io.OsmTransferException: java.util.concurrent.Exec
utionException: An error occured while downloading the data:
java.lang.IllegalArgumentException: Points of LinearRing do not form a closed li
nestring. Cause: java.util.concurrent.ExecutionException: An error occured while
 downloading the data:
java.lang.IllegalArgumentException: Points of LinearRing do not form a closed li
nestring
org.openstreetmap.josm.io.OsmTransferException: java.util.concurrent.ExecutionEx
ception: An error occured while downloading the data:
java.lang.IllegalArgumentException: Points of LinearRing do not form a closed li
nestring
        at org.openstreetmap.josm.plugins.ods.OdsDownloadAction$DownloadTask.rea
lRun(OdsDownloadAction.java:134)
        at org.openstreetmap.josm.gui.PleaseWaitRunnable.doRealRun(PleaseWaitRun
nable.java:93)
        at org.openstreetmap.josm.gui.PleaseWaitRunnable.run(PleaseWaitRunnable.
java:161)
        at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
        at java.util.concurrent.FutureTask.run(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
Caused by: java.util.concurrent.ExecutionException: An error occured while downl
oading the data:
java.lang.IllegalArgumentException: Points of LinearRing do not form a closed li
nestring
        at org.openstreetmap.josm.plugins.ods.OdsDownloader.subTask(OdsDownloade
r.java:167)
        at org.openstreetmap.josm.plugins.ods.OdsDownloader.run(OdsDownloader.ja
va:70)
        at org.openstreetmap.josm.plugins.ods.OdsDownloadAction$DownloadTask.rea
lRun(OdsDownloadAction.java:132)
        ... 7 more
INFO: GET https://api.openstreetmap.org/api/0.6/user/details (get number of unre
ad messages)

Dan vraagt Josm om bug report op te sturen, (niet gedaan):
kopie



{{{
Revision: 8491
Repository Root: http://josm.openstreetmap.de/svn
Relative URL: ^/trunk
Last Changed Author: Don-vip
Last Changed Date: 2015-06-16 23:27:08 +0200 (Tue, 16 Jun 2015)
Build-Date: 2015-06-16 21:45:58
URL: http://josm.openstreetmap.de/svn/trunk
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last Changed Rev: 8491

Identification: JOSM/1.5 (8491 en) Windows 7 64-Bit
Memory Usage: 977 MB / 1820 MB (495 MB allocated, but free)
Java version: 1.8.0_45, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Dataset consistency test: No problems found

Plugins:

- geotools (31126)

- ods-bag (0.5.1)
- opendataservices (0.5.1)
En andere


Last errors/warnings:
- E: org.openstreetmap.josm.io.OsmTransferException: java.util.concurrent.ExecutionException: An error occured while downloading the data:
- E: org.openstreetmap.josm.io.OsmTransferException: java.util.concurrent.ExecutionException: An error occured while downloading the data:
- E: org.openstreetmap.josm.io.OsmTransferException: java.util.concurrent.ExecutionException: An error occured while downloading the data:
- E: org.openstreetmap.josm.io.OsmTransferException: java.util.concurrent.ExecutionException: An error occured while downloading the data:
- E: org.openstreetmap.josm.io.OsmTransferException: java.util.concurrent.ExecutionException: An error occured while downloading the data:

org.openstreetmap.josm.io.OsmTransferException: java.util.concurrent.ExecutionException: An error occured while downloading the data:
java.lang.IllegalArgumentException: Points of LinearRing do not form a closed linestring
	at org.openstreetmap.josm.plugins.ods.OdsDownloadAction$DownloadTask.realRun(OdsDownloadAction.java:134)
	at org.openstreetmap.josm.gui.PleaseWaitRunnable.doRealRun(PleaseWaitRunnable.java:93)
	at org.openstreetmap.josm.gui.PleaseWaitRunnable.run(PleaseWaitRunnable.java:161)
	at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	at java.util.concurrent.FutureTask.run(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.util.concurrent.ExecutionException: An error occured while downloading the data:
java.lang.IllegalArgumentException: Points of LinearRing do not form a closed linestring
	at org.openstreetmap.josm.plugins.ods.OdsDownloader.subTask(OdsDownloader.java:167)
	at org.openstreetmap.josm.plugins.ods.OdsDownloader.run(OdsDownloader.java:70)
	at org.openstreetmap.josm.plugins.ods.OdsDownloadAction$DownloadTask.realRun(OdsDownloadAction.java:132)
	... 7 more
}}}

Vraag onderste bug report, start hij nu met java 64 op?

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. :smiley: :open_mouth:

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.

Kleinste bag gebouw van Nederland?

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.

Hoe zit het met **bag=conversie **gebruikt om het verschil te maken.

http://overpass-turbo.eu/s/bgZ

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.