Landuse overlap

Wat bedoel je?
Ik gebruikte de plug-in om wat mooie sloten uit de omringende landuse te knippen.

Even los van de plugin, was de vraag gesteld of er consensus is over wat mag wat overlappen. Er zijn daarover wel gedachten geformuleerd, maar ik zie geen duidelijke consensus.

Ik vind dat niet terug in de discussie. Het ging uitsluitend over de vraag wat er door de plugin wel of niet moet worden uitgesneden.

Ik heb er ook eens over na zitten denken. Het is best een lastig geval eigenlijk (vind ik).

De vraag is dus: wat mag overlappen?

Ik zat in deze richting te denken: als natural=* bepaalde landuse=* percelen van elkaar scheidt, dan mag het niet overlappen. In alle andere gevallen wel.
Nu ik het zo lees vind ik het niet echt een heel duidelijke stelling van mijzelf… Ehm, even een voorbeeld.

Stel er loopt ergens een rivier door een stuk farmland. Het Reitdiep bij Aduarderzijl bijvoorbeeld: https://www.openstreetmap.org/#map=16/53.3216/6.4709
Dat is toch een bepaald obstakel, daar kom je niet zo 123 doorheen. Verder is een landbouwperceel met landuse=farmland één afzonderlijk ding, ik bedoel: heel Noord Groningen wordt ook niet als één groot stuk landuse=farmland gemapt.
Je kan in deze situatie duidelijk zien waar het stuk *farmland *ophoudt: bij het water. Het water hoort hier niet bij het farmland. In zo’n geval zou het niet mogen overlappen.

Maar stel er loopt ergens een watertje door een industrieterrein, dan mag dat wel overlappen. Een industrieterrein is meer een naam die wij mensen aan een bepaald gebied geven, waar de grens nu overgaat in bewoonbaar gebied, of iets dergelijks, is niet altijd even duidelijk (toch?). Het is meer een vak dat aangeeft: alles wat in dit vak ligt beschouwen we als industrieterrein. Als daar een watertje doorheen loopt houdt het industriegebied niet ineens op naar mijn mening. Met *residental *is het eigenlijk hetzelfde, dat geeft ook alleen maar aan dat daar bewoonbaar gebied is.

Als het natural=* onderdeel is van een bepaalde area of een industriegebied, dan mag het elkaar overlappen. Als het een losstaand iets is en bepaalde landuses van elkaar scheidt of een grens vormt, dan mag het niet overlappen.

Wat vinden jullie hiervan, is dit een idee? Aanvullingen, kritiek, suggesties, alles is welkom!

[EDIT]
Als natural=* een door mensen aangewezen gebied doorkruist, dan mag het overlappen. Als natural=* een fysiek iets doorkruist of een grens vormt met een fysiek iets, dan mag het niet overlappen.

Even kort door de bocht …landuse= industrial en residential, Leisure=park zijn transparanten. Die kun je gewoon over water en land heen leggen. Ze overlappen. De plugin van KiaTIX houdt daar al rekening mee. KiaTIX heeft ook via het forum daar advies over gevraagd en gekregen.
Water en landuse… grass, forest e.d. mag niet overlappen. Daar is echt wel consensus over. Water en forest zou je anders door elkaar zien.
De plugin neemt veel werk uithanden. Wanneer je de perceelgrens in het midden van het water legt en de plugin draait kun je de boel keurig uitsnijden. Daarna draai je de Validator en verwijder je mbv “herstel” de lege nodes die overblijven.

Dit bedoelde ik eigenlijk te zeggen :).
Ik ga die plugin ook eens downloaden, ben benieuwd.

Hallo Kiaatix,

Marc Gemis vroeg me of dit al gemeld was in WeeklyOSM en dat was niet het geval, dus daar ga ik nu voor zorgen. Ik moet 'm zelf nog uittesten.
Wat ik niet terug vind, is de broncode. Overweeg je om 'm te releasen als vrije software onder een open source licentie? Of is het closed source?

mvg,

Polyglot

Het idee is om de code vrij beschikbaar te maken als de plugin helemaal goed werkt. Ik weet dat het nu soms nog niet helemaal goed werkt. Alleen wanneer dat is durf ik niet te zeggen…

Het had eigenlijk al gefixed moeten zijn. Maar er waren wat technische problemen (lokale versiegeschiedenis corrupt geraakt) waardoor ik eigenlijk de motivatie verloren had.

Maargoed, als blijkt dat er genoeg interesse is naar de cutout plugin dan kan dat ook weer voor extra motivatie zorgen natuurlijk.

Het kan dan juist een idee zijn de code beschikbaar te maken.
Dan kunnen anderen er fris van de lever naar kijken en mogelijk met ideeën komen.
In mijn carrière als software designer heeft het vaak goed gewerkt om collega’s naar je software te laten kijken. Reviewen heet dat, geloof ik :slight_smile:

In dit geval kan ik in ieder geval niet helpen. Ik kan ongeveer Java lezen, maar dan houdt het ook op.
Ik ben meer een fossiel uit de Cobol/Pascal tijd :slight_smile:

Ik gebruik de plug-in bijna dagelijks en ik moet zeggen, het bevalt me uitstekend.
In het begin werd ik nog al eens verrast door onverwachte meevallertjes, zoals in de omgang met een multipolygoon en slechts een enkele keer door een onverwacht minder positief resultaat. Echte fouten heb ik niet kunnen ontdekken.

Het achterlaten van ongebruikte nodes is een verschijnsel waar bewust voor gekozen is, maar waardoor minder nauwgezette werkers miinder acht zullen gaan slaan op de resultaten van de validatie. Dat heeft dan weer gevolgen als het zelfde gebied later door anderen bewerkt gaat worden.

Hallo KiaaTiX,

Als je van plan bent om de code vrij te geven, hoef je niet te wachten tot deze perfect is. Code is eigenlijk nooit ‘af’. Je zal altijd nog wel zaken vinden die beter kunnen.

Ik kijk er alleszins naar uit om de code eens te bekijken. Ik kan er waarschijnlijk wel wat van leren.

mvg,

Jo

Helemaal mee eens! Gooi gewoon op GitHub of GitLab. Niemand zal je afschieten op de kwaliteit of staat ervan zonder ook gelijk verbeteringen aan te dragen in de vorm van een pull request of bugreport.

Op een gegeven moment kun je ook besluiten de broncode bij het JOSM-project onder te brengen (terwijl je er zelf de controle over houdt). Ik heb dat met mijn eigen plugin ook gedaan.

Gisteren voor het eerst je plugin gebruikt. Heerlijk, wat een gemak :slight_smile:
Bedankt voor het werk, scheelt mij een boel werk.

Kleine update:

Gisteren de code weer werkend gekregen en het project wat opgeruimd. Zoals code voor de Tilburg BGT import er uit gehaald.

De broncode is nu hier te vinden:
https://github.com/bdxd111/JOSM-Polygon-Cut-Out

Er is dus ook meteen een nieuwe versie van de plugin beschikbaar.

Goed werk!

In dit draadje wordt een paar keer gesproken over de “Validator” van JOSM.
Ik gebruik die nooit. Ik druk op “Upload”; meestal verschijnen dan een paar fouten. Dan cancel ik de upload en los de fouten op. Ik druk eigenlijk zo vaak op upload en cancel tot ik geen foutmelding meer krijg.
Blijkbaar wordt een validator gestart als je op upload klikt. Is mijn conclusie juist?
En is dat dezelfde validator?

Kogacarlo… dat klopt, maar nadat je e.e.a. hebt verbeterd bv. die lege nodes verwijderen nadat je de plugin hebt gebruikt via Herstel. Dan kun kun je het best de validator nog een keer extra draaien.

Ik heb kleine verschillen gemerkt tussen de validator, die je met ‘upload’ start en de validator die je uit het venster start.
Eén van die verschillen is dat de validator uit venster kan werken met de selectie die je maakt.
Dat is soms wel handig als je ergens bezig bent waar een ander veel validatie fouten achter heeft gelaten.
Gewoon maar eens uitproberen.

De validator vanuit de upload checked enkel de objecten die je zelf net gewijzigd hebt.

De handmatige validator checked alle objecten (beperkt tot een eventuele selectie), waardoor je ook fouten die anderen hebben achtergelaten kunt detecteren (en eventueel oplossen als je daar op dat moment tijd voor en zin in hebt).

De validator loopt met een t dus de validator checkt met een t :wink:
Ik ga die validator wat vaker gebruiken :slight_smile: