Idee om wat met BAG te gaan doen

Het is mooi als straks alles er in zit. Helaas is niet alles zonneschijn. Het lijkt erop of nog al wat importeurs geen tijd hebben voor de nacontrole.

Als dit zo blijft, dan geven we de DWG een mooi extra argument om te zeggen: Zie je wel. Slechte import.

P.S. Dat de links hierboven gecentreerd zijn op Zeist heeft niets te maken met de plaatselijke data, maar wel met het bevolkingszwaartepunt van Nederland.

Verbaasd over de vele overlapping building.
Osmosis:
Ik heb er een aantal nagelopen maar na download geeft de Josm validator geen melding.
Na controle heb ik op veel plaatsen gedaan, niet alles is oplosbaar. Josm validator.
Op Urk ben ik nog niet uit wat het beste is.
Osminspector:
adressen die de naam van het water hebben.
adressen op de parkeerplaatsen benzinestations snelwegen.

argrument:
slecht import, nou niet, bekijk eerst even de kwantiteit en de kwaliteit vertaalslag die gemaakt is.
Beoordeling van de brondata, de bron niet zuiver genoeg maakt het nog geen slechte import.
Het import tool JOSM zou je dan kunnen bekritiseren als een slecht importtool. Validator, failure.
Osminspector geeft ook zaken aan die eigenlijk niet fout zijn.

Al met al slecht import, dacht het niet.
We zullen het moeten doen met de tools die we hebben.

Heb de osmosislink maar eens naar de plaatselijke Gemeente Bag controleur gezonden, weet hij waar hij nog moet zoeken.

Ik ben net te weinig technisch aangelegd, kan 1 van jullie op http://josm.openstreetmap.de/report een goed beschreven melding maken van deze bug in de JOSM validator?

ps het oplossen van de osmose meldingen (de OSMI had ik al opgelost) in ‘mijn’ gebied geeft gelukkig weer voeding aan mijn OSM verslaving in deze zomermaanden :slight_smile:

Het gaat er niet om wat wij een goede of slechte import vinden. Het gaat erom wat er één is naar de maatstaven die gehanteerd worden bij het goed- of afkeuren van een import. Als de bron data van slechte kwaliteit is en je hebt als importeur ontwerper geen plan om die fouten allemaal te verbeteren voor je de data importeert, dan wordt er normaal geen groen licht gegeven voor de import.

Dat de communicatie in december in de soep gelopen is is vervelend, maar dat geeft ons geen vrijbrief om maar wat te doen. Sterker nog het is waarschijnlijk slimmer om te zorgen dat we het extra netjes afwerken.

Ik wilde een nuance aanbrengen

“Beoordeling van de brondata, de bron niet zuiver genoeg maakt het nog geen slechte import.”
Dat zeg ik, de import, hoe goed kunnen wij die doen.
Josm validator was juist een graadmeter hoe goed de data van BAG was.
Nu na deze constatering zeggen we ook niet we doen JOSM in de ban, is geen betrouwbare uploader naar OSM.
Inzet is, een 100% goede invoer.
Vergt nu alleen wat meer nawerk.
Dat zal even zijn tijd kosten.
Daar kunnen anderen ook met mee helpen.

Eens. Osmose is trouwens pas net beschikbaar in Nederland. De DWG had geen problemen met de validatie die werd voorgesteld op basis van JOSM. Eén list member, tevens DWG lid, had alleen wat vraagtekens bij een drietal tags die we gebruiken (de ref:BAG, de source en de source:date).

Wat betreft de OSM Inspector heb ik vorige week een e-mailtje naar de makers gestuurd met de vraag de controle wat stricter in te stellen.

Het viel me namelijk op dat vanaf zoomniveau 17 er toch regelmatig ook lijntjes vanaf adresnodes zichtbaar worden naar straten een paar dorpen verderop. Dus zodra je in een plaats een “Handelstraat” omzet naar “Händelstraat”, verdwijnen in de plaatsen eromheen de rode bolletjes als sneeuw voor de zon terwijl de lokale straat nog niet gecorrigeerd is.

In de OSM Inspector wiki staat dat ze slechts in een straal van 1km zoeken. In de praktijk zie ik dat straten in een straal van 5km gevonden worden, waardoor onbedoeld adressen “goedgekeurd” worden die dat eigenlijk niet behoren te zijn omdat de match behoorlijk uit de buurt gevonden wordt.

Dus als in reeds gecontroleerde gebieden ineens weer rode bolletjes opduiken zou mijn verzoek daarvan de oorzaak kunnen zijn.
Overigens heb ik tot op heden nog geen reactie gehad van ze.

cartinus heeft een punt dat de achterstallige nacontrole een mooi argument is voor de mensen die tegen deze import zijn (alhoewel ik de indruk heb dat de storm is gaan liggen).

ik zal na gemeente teylingen beginnen met mijn nacontroles voordat ik een nieuwe gemeente kies.

het zal mij persoonlijk een worst wezen of er Burg. of Burgemeester in de straatnaam staat. daarom ben ik vooral doorgegaan met importeren maar uiteraard ga ik voor alle gemeenten die ik gedaan heb ook de nacontrole nog doen. dat verwacht ik ook van alle anderen die nu BAG aan het importeren zijn.

Ik heb ook contact gehad met OSM inspector.
Daarop reageerde Herr Ramm, dat was al in april.
Was ook meerdere nodes rood die ik niet weg kon krijgen, terwijl de naam van de weg 50 meter ervoor goed was. (zelfs naam eraf gegooid, geupload afgewacht osmi, naam er weer op, osmi, probleem bleef)

Opgelost, …

Dus niet geknipte (lange) wegen met een naam, geven problemen, daar wordt vanuit het middelpunt gedacht, zoals ik het begrijp.
En dat huis lag aan het einde van zo’n weg.

Daarna heb ik wat voorstellen gedaan in Mei (7) voor OSMI, betreffende welke zoom zichtbaar, zwarte lijnen en of afwijkende lijnen rood konden worden en op ander zoom niveau zichtbaar.

En ook het aparte stratengeval in URK beschreven, met link naar OSMI.

TOT op heden geen antwoord gehad op mijn voorstellen.
Is ook geen must. Elke vraag/voorstel behoeft geen antwoord.
Bij zo’n Bag import word door een kleine groep op basis van specifiek doel, met hoge intensiteit gebruikt gemaakt van OSMI. En daardoor gebruikerservaring op bouwt gevolg een voorstellen naar OSMI, delen ervaring is positief.

Nu, vraag ik met af of voorbeeld Urk de tricker is tot zijn reactie naar de Bag import ontwikkelaars.
Urk is een apart geval zeer afwijkend in Nederland en niet te voorzien.

Crossing building zijn fout, zitten in brondata, Josm upload, de overblijvende fouten waren niet te voorzien. Taak Bagimporteur.

De brondata namen zijn officieel, dus kwalitatief hoog, import van deze data is correct. Hier zou de import hoge punten scoren.

Dat de wegen nu vaker verkeerde namen hebben was een reeds bestaand probleem, het verschil is niet toe te schrijven aan de BAG import.

Bag import heeft het juist bloot gelegd. Dit is ook positief
Inzichtelijk gemaakt door de inspectors /validators.

Hier houd eigenlijk de actie van de Bag importeur op.
De Bag importeur, weet wat hij heeft gedaan waar de problemen liggen, verhoudingen, ik kan niks anders zeggen dat op dat gebied ik het een kwalitatief hoge import vindt.

Maar de Bagimporteur onder deze naam of eigen ging verder, deze bestaand fouten op wegen (namen) worden als extra inspanning meegenomen en dat is te loven.
Waarop de hele community ook actie kan ondernemen. Inspringen.

En zo zijn er ook heel veel wegen rechter gelegd.
Ik ben althans veel verder gegaan dan alleen bagimport en bagimport fouten, dit heeft dat ook veel meer tijd gekost, wat ook als een meerwaarde gezien kan worden.

Over welke tags dat is een ander verhaal.

Ik heb een probleempje:
De BAG import plug-in overschreidt de polygon grenzen bij import van data.
(ook de ODS laag gaat buiten de polygon)

Tot op heden weet ik nog niet wat ik verkeerd kan doen. Zijn er meerdere personen die dit weleens hebben ervaren, en wat is de oplossing?
Als bijlage heb ik rar bestand 3 polygons in een bijgevoegd, zou iemand deze stukjes willen importeren met de BAG plug-in?
(natuurlijk niet uploaden, maar dat lijkt me logisch)

edit: link werkt inmiddels goed.

Getest met je polygonen, bij mij gaat het ouderwets goed

In het begin deed ik de nacontrole nog via OSM Inspector, maar dat is erg bewerkelijk. Kijken of OSMI, dan laden in JOSM, fixen en naar de volgende.

Sindsdien heb ik na het uploaden steeds de FixAddresses plugin gebruikt. Met deze plugin spoor je snel situaties op waarbij adresnodes geen matchende straatnaam hebben.

Helaas werkt deze plugin niet al vóór het uploaden. De plugin werkt blijkbaar alleen met data die al in OSM staat, dus alleen met positieve ID’s.

Door een nieuwe tested 7182.jar te downloaden werkte het weer op de juiste manier!

Sinds kort heb ik Windows 8 geïnstalleerd, ik ervaar dat JOSM zeer hakerig (freezes) reageert, heeft iemand hier een oplossing voor?

Iets te vroeg gejuicht.
Dit filmpje laat zien wat er gebeurd.

Edit:
Bij start van JOSM wordt de data van de eerste polygon goed gedownload, wil je daarna een 2 polygon downloaden, dan importeert hij ook de gebieden van de voorgaande polygons. Dit is structureel, dus als je een derde polygon wil downloaden heeft hij de data van alle 3 de polygons in de ODS en OSM laag geïmporteerd etc.
Nu weet ik niet of dit aan Windows 8, een instelling van JOSM of aan de plug-in ligt. Ik blijf proberen of ik de oorzaak kan vinden, en sta open voor meedenken hierin.

Inmiddels geprobeerd:
Het bestand C:\Users\Myckel\AppData\Roaming\JOSM\preferences.xml verwijdert, zodat de standaard JOSM instellingen als basis wordt ingesteld.
De map C:\Users\user\AppData\Roaming\JOSM\cache leeggemaakt.
De map C:\Users\Myckel\AppData\Roaming\JOSM\autosave\deleted_layers leeggemaakt.
Instelling autosave.deletedLayersBackupCount van waarde 5 naar waarde 0 gezet.

Niets van bovenstaande heeft tot nu toe tot de oplossing geleid.

@Commodoortje
Werkt bij mij ook zo. Voordat je de tweede polygoon selecteert, moet je eerst “Disable ODS” aanklikken de tweede polygoon selecteren en vervolgens weer “Enable ODS”
Ik open meestal JOSM nog een keer. Je hebt JOSM dat twee keer open staan. Terwijl de ene aan het uploaden is, kun je in de tweede geopende JOSM met de volgende polygoon aan de slag. Zo krijg je een doorlopend proces en loopt niet tegen jou probleem aan.

Je kunt zelfs met twee (of drie) geopenden JOSM’s twee polygonen tegelijk uploaden.

René.

In Windows 7 was dit niet zo, vandaar.
Vermoedelijk zit het in Windows 8?
Tijdens de voorbereiden van een te importeren gemeente kijk ik meestal eerst of de data goed wordt ingelezen.

Dank voor je melding dat je identieke ervaringen hebt.

Het is mij in Windows 7 ook overkomen. De workaround Disable/Enable ODS is werkbaar.

RIVW,

en wat is dan je respons of de upload tijd ?

Geen idee, maar je hoeft in ieder geval niet te wachten tot JOSM klaar is met uploaden voordat je met de volgende polygoon kan beginnen.

René.

Rene, maar als je de pc na afloop wil sluiten, dan is de wachttijd van (> 60 min) toch een aardig gegeven. De PC staat niet dag en nacht aan, ik ben weleens verkennend buiten en lees ook wel eens wat. Verkennen is trouwens een aantrekkelijke kant van dit werk.