Help! Bij het wegwerken van dubbele knopen vanuit Osmose heb ik aan dit gebouw gezeten: https://www.openstreetmap.org/way/798411688
Delen van het gebouw zijn ook apart nog een keer getekend, daardoor waren er veel duplicate nodes, maar nadat ik er een aantal gemerged had, kreeg ik van JOSM op mijn kop dat er overlappende gebouwen zijn.
Ik heb gekeken of ik het kan herstellen maar ik begrijp het denk ik niet goed, ben duidelijk buiten mijn terrein.
Ik wil het wel zelf herstellen, dan zou ik graag wat tips willen wat ik fout gedaan heb en wat ik moet doen. Of misschien moet het weg en opnieuw vanuit de BAG komen?
Als ik het goed zie heb je daar aan dat gebouw gewerkt en met changeset 93948592 de wijzigingen naar de server gestuurd.
Die changeset kan ik eenvoudig reverten. Dan is de oorspronkelijke situatie hersteld.
Het gebouw bestaat uit een buitenomtrek. Als het goed is komt die dus uit de BAG.
Binnen die buitenomtrek zijn twee building:part= getekend.
Dat betekent dus dat er twee lijnen op elkaar liggen.
Als dan de knopen niet zijn samengevoegd of als er meer knopen zijn getekend op één lijn en niet op de buitenomtrek, dan kan dat allerlei foutmeldingen veroorzaken.
Meestal kun je die foutmeldingen gewoon negeren.
De changeset is aangemaakt met Osmose.
Meestal door onkunde van de gebruiker worden er door Osmose meer fouten gemaakt dan dat er goede wijzigingen ontstaan.
Maar dat is ook maar mijn persoonlijke mening.
Na de revert ga ik eens kijken wat ik kan ontdekken aan het oorspronkelijke gebouw.
PS waarom beslaat de changeset compleet Walcheren en Zuid-Beveland ?
Dat is veel te groot als je alleen aan dat gebouw werkt.
Ik had zelf hier en daar wegen en knopen gedupliceerd en JOSM had dat doorgelaten. Daarna heb ik her en der duplicaten weggewerkt. Daarbij zag ik ook cluster duplicate nodes aan dat gebouw, maar ik had niet door dat er gebouwen binnen gebouwen lagen en dat die dubbele knopen moeten hebben. Vind ik ook vreemd… maar ik had er dus af moeten blijven, en zowizo niet kombineren met andere akties.
Ik ben ook bang dat er wijzigingen aan dat gebouw in verschillende changesets zitten. Niet mijn beste prestatie, dit.
Maar de bedoeling is wel dat de buitenomtrek waar van toepassing samenvalt met de gebouwdelen, en dan niet met dubbele knopen? Want de dubbele knopen werden door Osmose als fouten aangemerkt nog voordat ik er aangezeten had.
Op zich mankeert er eigenlijk weinig aan het gebouw.
Er is egenlijk geen reden om het gebouw aan te passen.
Wat Osmose meldt moet je dus zelf interpreteren en vervolgens cuncluderen dat je die meldingen kunt negeren.
Op slechts enkele plaatsen wijken de lijnen van de parts af van de buitenomtrek.
Bijvoorbeeld in de NW hoek zie ik twee nodes die vlak bij elkaar staan. Dat betekent dus dat de lijnen niet op elkaar liggen, maar los van elkaar. Dat is geen bezwaar.
Als ik het gebouw zou tekenen dan zouden die twee nodes zijn samengevoegd op de hoek van het gebouw.
In de uitbouw van het midden van het W deel van het gebouw wijkt de lijn af van de buitenomtrek. Die lijn zou ik dus vastmaken aan het hoekpunt dat daar ligt.
In de lange Z lijn van het O gebouw zie je een drietal kruisjes die het midden van een lijndeel aangeven.
Die lijnen liggen dus niet op elkaar. De node in het midden zou ik dus verwijderen.
Maar zo een wijziging is niet dwingend voorgeschreven.
Aan de O-zijde heb je ook geprobeerd om de uitbouwen te verwijderen.
Die zijn echter correct op de kaart gezet. Ze zijn ook aanwezig in de BAG.
In zijn algemeenheid kun je stellen dat er in NL heel veel lijnen (vooral landuse) op elkaar liggen.
Dat heeft bij mij tot een storings-reactie geleid: Voor ik iets ga wijzigen haal ik altijd alle lijnen uit elkaar.
Dan weet ik tenminste zeker dat ik niets onbedoeld naar een verkeerde positie sleep.
Inderdaad is op vrijwel alle hoekpunten gewerkt met een dubbele knoop.
Wat dat betreft heeft Osmose het dus correct gemeld.
In principe zou ik dat hebben getekend met één knoop per hoekpunt.
Dus de dubbele knopen samenvoegen tot één knoop lijkt mij een correcte actie.
Als ik de revert nu upload, dan kun je nog eens een poging wagen.
Ik heb nu alle dubbelknopen to enkele knopen samengevoegd en alle overbodige tussenknopen verwijderd.
De vormen zijn niet veranderd. De gebouwdelen liggen volgens mij volledig binnen het gebouw.
Aangepast in 1 changeset: https://www.openstreetmap.org/changeset/93971140#map=19/51.46479/4.03608
Toch blijft JOSM klagen over overlappende gebouwen. Het oostelijke deel vindt-ie goed; het westelijke deel (office) en de buitenomtrek zijn volgens JOSM overlappende gebouwen.
Ik zie eigenlijk geen principieel verschil tussen de gebouwdelen. Beide hebben een stukje wat niet samenvalt met de buitenomtrek, en beide zijn building:part, geen building. O ja, het office-gedeelte heeft twee binnenlijntjes.
Dus het klopt dat de polygonen overlappen, maar gebouwdelen overlappen toch altijd het geheel?
Om de zaak te perfectioneren kan er nog een relatie worden toegevoegd die de outline en de building:part omvat.
Dan is de melding van overlappende gebouwen ook verontzijdigd.
Als een gebouw building:parts bevat dan moet ieder deel van het gebouw als building:part worden ingetekend omdat het anders niet zal worden gerenderd in 3D. Als alle building:parts binnen het gebouw passen dan hoeft er geen relatie te worden gebruikt.
Dat is hier het geval. maar er is ook een stuk binnen het gebouw waar geen building:part op staat.
Heb jij een verklaring voor de foutmelding “overlappende gebouwen” in JOSM?
Daar hoort een building:part in te komen, vooropgesteld dat de omtrek klopt. Je kunt bij gebrek aan meer gegevens een building:part=yes maken zonder overige gegevens.
Ik vermoed dat de building:parts hier zijn gebruikt met de verkeerde reden, namelijk om het kantoor te scheiden van de rest van het gebouw, dus op functie. Aangezien die twee delen ook fysiek verschillen is het echter niet verkeerd.
Een building:part wordt uitsluitend gebruikt voor 3d rendering om de uiterlijke verschijningsvorm van een gebouwdeel aan te kunnen geven, bijvoorbeeld wanneer het gebouw uit twee delen bestaat die allebei een andere hoogte hebben of een andere kleur.
Het is mogelijk om op een building:part=* een waarde te zetten maar die wordt alleen door de 3d renderer gebruikt. Als er bijvoorbeeld building:part=garage op staat en als de 3d renderer slim genoeg is dan zoekt hij uit welke muur het dichtst bij een weg ligt en tekent daar een garagedeur op. Huizen en kantoren krijgen ramen. Enzovoort.
Dat houdt in dat alle gegevens die in een building:part worden gestopt voor alle overige applicaties verborgen zullen blijven. Je raakt deze dus kwijt, om het zo te zeggen.
Sjeez zeg! Heb je alle knopen 1 voor 1 verschoven om dat te ontdekken?!
Ik heb de knoop gekoppeld en nu is de foutmelding weg!
Ik heb geen duidelijk beeld van dat voorstukje, maar omdat er deels gras onder ligt en je er een soort van pad in ziet lopen denk ik dat het een entreeluifel is.
Al met al was dit heel verhelderend, bedankt allemaal!
Heb even gekeken om ervan te leren…
Ik zie twee overlappende adresnodes met grotendeels identieke tags. Gaat er iets ontbreken als de node met de oudste source:date wordt verwijderd, of is dat de node van het kantoordeel? Als beide nodes moeten blijven staan, zou ik ze iets uit elkaar trekken en is er dan een manier om aan te geven bij welk gebouwdeel ze horen? Zo zijn b.v. huisnummer en postcode, etc. identiek, met uitzondering van de source:date. De tags ref:bag ontbreken - dat zou m.i. het onderscheid kunnen zijn.
Edit 2020-11-13. ref:bag staat op de contour natuurlijk, sorry.
Nog eentje: ik heb hier https://www.openstreetmap.org/way/267721239 een gebouw wat in zijn geheel gedubbeld is. Een nieuwe bagimport is over de oude heen gezet, denk ik.
Gewoon de oude weggooien?