Aankondiging gebruik BGT.

Communities Nederland (Netherlands)
#1

Na de toestemming tot gebruik BGT.

https://forum.openstreetmap.org/viewtopic.php?id=59021

Hebben we de ondergrondlagen lagen gebruikt om lijnen uit te lijnen/te verleggen of nieuw in te tekenen.

Ik zal me de komende tijd meer gaan toeleggen om de belijning uit een bestand over te nemen.

De een vindt dit een import, de ander vindt het nagenoeg geen verschil met overtekenen.

Als men het als import ziet bij deze de melding.

Zeer kleinschalig overzetting. Handmatig.
De belijning, zoveel mogelijk gemerged met het bestaande.
Alle data uit de BGT kan worden overgezet.

Allroads

#2

Beperk je je tot een bepaalde regio?

#3

Hoi Allroads,
mijn sympathie heb je voor dit voorstel, er zijn situaties waarbij overtekenen (wat inderdaad is toegestaan en zeker ook zinvol kan zijn) en op kleine schaal bestand invoegen nagenoeg geen verschil maakt mits dat zorgvuldig gebeurt in relatie tot bestaande data (conflation) en ik
geloof dat je dat zal doen.

Gebruik van de bron staat idd niet ter discussie: dat is toegestaan en de bron is -in ieder geval in mijn gebied/aandachtsgebied (water in Rijnland)- van onovertroffen kwaliteit gebleken.

Ik heb zelf ook veel bgt-data overgetekend bij het oplossen van landuse-overlap in polders (oa rond de Kaag) en hoewel de data onovertroffen is (en de gevonden werkwijze met een multipolgoon per polder goed werkt) begon op een gegeven moment het overtekenen van een beschikbaar bestand zelf toch wel zinloos (en fysiek pijnlijk) te voelen.

Eerder heb ik in dat kader in de wiki volgens weleens iets gelezen van een aantal nodes (1.000?)vanaf waar iets doorgaans als een import word gezien (in de zin dat je de volledige import guidelines met wiki, aparte user-account etc. ) zou moeten volgen, maar dat kan ik nu zo snel niet vinden.

Zelf heb ik zoals gemeld een tijdje een plan voor gebruik van watervlakdata uit de bgt-bestanden.
Op zich is dat helder afgebakend per polder en alleen daarbinnen (dus niet het boezemwater dat de grotere vlakken / meren en bekende vaarten vormt), maar dat verschilt zo te lezen in schaal wel van jouw voorstel, waardoor mijn plan ben ik bang toch volgens het complete import proces moet.

Ben nog steeds)moed aan het verzamelen ben om het bureaucratische import-proces op te starten, ook omdat voorstellen soms vooral worden opgevat om vooral zoveel mogelijk bezwaren te bedenken in plaats van af te vragen of dit ondanks beperkingen/bedenkingen een stap vooruit kan zijn.

Succes, ben benieuwd naar je bevindingen, misschien interessant om een voorbeeldje te delen als je iets hebt afgerond met opgedane ervaringen n tips/tricks ivm combineren bgt-data in de bestaande datastructuur?

#4

@Multimodaal:

Over die import:
https://wiki.openstreetmap.org/wiki/Import/Guidelines

Laat ons zeggen dat er eigenlijk een vrij complex documentatieproces aan een importprocedure vooraf hoort te gaan, vooral als dat ‘in bulk’ gebeurt.
Ik weet niet of er een concreet cijfer op geplakt wordt, maar 1000 lijkt me een redelijke aanname tussen ‘ik had even iets nodig voor deze specifieke regio’ en ‘ik heb er een hele zooi in gepleurd’.

Over het gebruik van een aparte account voor imports (uit de eerdere link):

#5

Nee.

#6

Dan snap ik je denk ik nog niet helemaal. Wat is er dan ‘Zeer kleinschalig’? Wat ga je precies doen (handmatig overtekenen, in JOSM inporten of automatische tools gebruiken)?

#7

Kleinschalig ==> kleine gebieden overnemen ==> enkele polygonen. Copy/paste, belijning/punten.

#8

Inmiddels heb ik bijna mijn hele dorp uitgelijnd op basis van de BGT omtrekgericht. Dit heb ik handmatig maar belachelijk nauwkeurig gedaan en altijd in combinatie met lokale kennis en surveys. Je moet wel weten wat de lijnen betekenen en dat is op een luchtfoto niet altijd goed te zien. In de enkele gevallen dat de belijning niet klopte of verouderd was heb ik uiteraard wel mijn eigen uitlijning gekozen.

Ik sta positief tegenover een proef met semi-automatisch overnemen van de BGT-lijnen als een aantal richtlijnen in acht worden genomen. Dat zijn wat mij betreft:

  • kleinschalig waarbij elke lijn handmatig wordt gecontroleerd
  • toepassing niet eenzijdig op basis van de BGT, dus i.c.m. minimaal één andere bron (zoals luchtfoto of survey)
  • kiezen voor gebieden waar weinig mapactiviteit plaatsvindt
  • ervaringen delen op het forum
#9

Ja leuk!
We flikkeren Kollum gewoon van de kaart; alles wat jij toevoegde is weg.
En dan zetten we een kopie van de BGT in OSM! lekker makkelijk :slight_smile:
Of bedoelen jullie dat niet?

#10

Er was ooit consensus om niet grootschalig te importeren met als voornaamste argument dat dit ondoenlijk veel handwerk met zich meebrengt. Dit betekent echter niet dat het niet kleinschalig kan gebeuren. Mij lijkt dit zinniger dan natekenen.

Ik sta positief tegenover dit voorstel. Wel heb ik wat vragen. Waar download je de data? Hoe zet je die om naar osm formaat? Neem je ook tags over uit de BGT?
Ik heb er op zich vertrouwen in dat Allroads dit zorgvuldig zal uitvoeren, maar als meer mensen BGT data naar osm gaan kopiëren lijkt het mij noodzakelijk om hier afspraken over te maken. Dingen als: wat wel/niet importeren en hoe zetten we tags om naar osm tags. Andries draagt hierboven ook een aantal zinvolle punten aan.

Ik wil voorstellen dat Allroads een stuk importeert in een of meerdere changeset en daarna dit forum de wijzigingen laat beoordelen.

P.S. kan iemand mij uitleggen hoe je BGT data download? Ik zou dit graag een keer bekijken om een betere mening over dit onderwerp te kunnen vormen.

#11

Allroads, ik zag dat je ook in mijn dorp wat wijzigingen hebt gemaakt.
Heb je dat bewust gedaan zodat ik gemakkelijk kan meekijken hoe het uitpakt?

In elk geval geef ik er nu graag een reactie op. Het betreft een locatie aan de rand van het dorp en tevens op de grens van waar ik reeds exact heb uitgelijnd op basis van BGT (daarom het verschil in nauwkeurigheid tussen de groenstroken aan de overzijden van de weg).

Het type wijziging waarom het gaat ligt in het verlengde van met name deze discussie en in mindere mate deze discussie.

Hier een afbeelding met nummering door mij toevoegd:

1 = highway=footway, crossing=unmarked, surface=asphalt
2 = highway=footway, surface=paving_stones
3 = highway=footway, footway=crossing, crossing=unmarked
4 = highway=footway, footway=sidewalk, surface=paving_stones
5 = highway=footway, footway=sidewalk, surface=paving_stones
6 = highway=footway, footway=crossing, surface=paving_stones

Dit is het bijbehorende beeld van Google Streetview.
Dit is de wijzigingenset in achavi.

Way 5 was van mij, met de huidige tags, maar die liep door waar nu way 6 loopt.
Je hebt dat stukje geknipt om er crossing van te maken. Ik vind dit zelf geen goede praktijk. Nee, het trottoir loopt uiteraard niet door tot het midden van de weg maar een oversteek is er ook niet.
De vraag is: moet de way daar een afwijkende tag hebben om de highway=footway te rechtvaardigen. Het antwoord is mijns inziens: nee. Onderbouwing: lijnelementen zijn een schematische weergave en een way wordt bij voorkeur in het midden van de daadwerkelijke wegbreedte gelegd maar representeert de gehele weg. Het trottoir ligt in werkelijkheid direct tegen de weg aan en daarom is het doorlopen van de highway=footway, footway=sidewalk gerechtvaardigd.

Hetzelfde speelt bij way 4: in werkelijkheid ligt het trottoir tegen de weg aan. Je hebt een hele korte verbinding gemaakt tussen weg en trottoir om ze met elkaar te verbinden. Het lijkt alsof je met het opknippen van die gehele oversteek in vier stukken wilde ontsnappen aan de schematische weergave maar way 4 valt nu samen met een halve dwarsdoorsnede van het trottoir.
Way 1 en 4 bestaan in feite niet of in elk geval niet als losse delen. De door jouw gekozen werkwijze vind ik zelf niet houdbaar. Ik ben benieuwd hoe anderen ernaar kijken.
De toevoeging van een oversteek (unmarked) op deze plaats vind ik wel terecht omdat die door het verbindingsstuk t.h.v. way 2 wordt gesuggereerd (ik steek daar zelf ook regelmatig over). Ik zie echter geen reden om deze in vier stukken op te knippen. Als er een knip zou moeten zijn dan op de zuidelijke wegrand: way 1 en 2 samengevoegd met tags van huidige way 2; en way 3 en 4 samengevoegd met tags van huidige way 3.

Verder vraag ik me af hoe je de ondergrond van way 1 en 2 kent aangezien er geen Mapillary-beelden van zijn.

Kortom: deze manier van gebruik van de BGT, namelijk het opknippen van een way zodra die een BGT-lijn kruist, vind ik geen goed idee. De richtlijnen en samenhang binnen OSM zouden voorrang moeten hebben (met daarbij opgemerkt dat deze vorm van detail of micro mapping nog in ontwikkeling is en dus nog weinig is besproken en gedocumenteerd).

#12

Ben het hartroerend eens met Andries.
Veronderstel dat er een wandelroute over deze footways loopt.
Dan ben ik, na de import, in het ongunstigste geval, dus 4 delen van de wandelroute kwijt.
In het gunstigste geval hebben alle delen nog wel de relatie met de wandelroute, maar staan ze gegarandeerd in de verkeerde volgorde en is de route dus op meerdere plaatsen onderbroken.
Dat lijkt mij dus geen goed uitgangspunt.

Overigens lijkt het voor het aanpassen van landuse lijnen een prima methode.

#13

Dit wordt wel heel erg gepeuter op de milimeter.
Naar mijn idee heeft Andries volkomen gelijk.
1+2+3+4 is gewoon 1 lijn, een footway en hetzelfde geldt voor 5+6, ook 1 lijn.
Ook als je een route overheen moet leggen, wordt je helemaal gek van al die losse stukjes.
En ook op zulke kleine stukken maakt de surface helemaal niets uit. Dan neem je voor de hele lijn het meest voorkomende wegoppervlak en je gaat niet peuteren met een stukje asfalt, stukje tegels. Toe nou.
Bovendien is er een praktisch probleem met al die losse stukjes. De kans dat de lijn verloren gaat is best groot. Allemaal nodes en die kunnen zo verschuiven. Bijv. als iemand bij editten per ongeluk zo’n node beet heeft.

#14

Ja, bewust, nadat ik daar via een zoekmelding, daar uit kwam. Reeds aangelegde tag crossing unmarked, ik was op zoek naar crossing=island en hoe te taggen. Van waar tot waar.
BGT en gebruik, er is veel te bespreken, als ook de combinatie area:highway gebruikt gaat worden, mijn insteek van dit topic is overnemen belijning door copy/paste etc.

Dit is met het “natekenen BGT gebruik” gemaakt. Waarvoor ik hier in dit topic geen melding doe, want dat is algemeen geaccepteerd.

Halve oversteek is zo’n discussiepunt, (ik heb het daar even zo gelaten, om het routerend te houden) op meerdere plaatsen zijn er halve overgangen, dit heeft te maken met de twee lijnen intekensystemen, sidewalklijn footway of niet, de overgang, een bestaande oplossing. Daar verandert wel de surface, kan reden van knip zijn (maar niet aangepast naar asphalt, mijn fout), verdergaand, dat er een verschil kan zijn in hoogte van kerbs. Wat weer invloed heeft op bepaalde soorten routering (in ontwikkeling). Node, voorschot op mogelijk latere BGT area:highway inbreng met ook surface.
Sommige BGT lijn overgang, lopen vloeiend door. (surface) geen reden om te knippen.
Ik leg veelal een node neer waar geknipt zou kunnen worden. Dit omdat het ook een mooi punt is om uit te lijnen.

lijnelementen, moeten die altijd later een verbinding hebben met de area:highway polygonen. Reden, om daar alvast een node neer te leggen.
De verbindingen zijn er al, kijkend naar pedestrian en area.
Gevolg is node op BGT lijnen, er is dus een verschil tussen node op de BGT lijn of knip op de BGT lijn.

Routes moeten aangepast worden in de relaties, is geen reden om er van af te zien. Valt onder verkeerde mapping/tagging. Heeft niks met het gebruik van BGT te maken. Er wordt zo vaak geknipt om reden van maxspeed, surface, traffic_calming, etc.

#15

Ja ik zie nu dat ik zelf die oversteek al had ingetekend en dan als één way met de tags highway=footway, crossing=unmarked, surface=paving_stones. Die laatste omdat het stukje oversteek tussen fietspad en weg uit tegels bestaat maar de tag had ook achterwege kunnen blijven. En bij nader inzien is crossing=unmarked overbodig omdat die al op de kruisende node staat en zou footway=crossing juist wel passend zijn, ook in lijn met wat de wiki’s voorstellen.

Het leek me inderdaad handmatig BGT gebruik… ik was wel benieuwd naar je bedoeling.
Je houdt dus serieus rekening met (grootschalig) toekomstig ‘area mapping’ van wegen en paden.

Het plaatsen van nodes op de dwarslijnen van de BGT, zonder ze onnodig te knippen, is wel een goed idee. Dat ben ik zelf de laatste tijd al gaan toepassen. Bij eventuele latere verschuiving van een way of een node, bijv. bij een kruispunt, blijft de rest dan keurig op zijn plaats.
Opknippen om een overgang van maxspeed of surface doe ik wel eens maar niet speciaal voor hele korte stukjes. Bijv. een met klinkers geaccentueerd kruispunt waar asfaltwegen samenkomen zou naar mijn idee niet aan alle vier kanten geknipt moeten worden, ook niet als de klinkers 15 meter in een richting doorlopen.

Wat betreft routes is het in de eerste plaats zo dat degene die gaat knippen rekening hoort te houden met routes die er lopen. Dus zolang je in zulke gevallen de routes meteen corrigeert is daar geen direct probleem.
Echter, bij nieuwe of vernieuwde routes gaan de mappers die zich met wandel-, fiets- en busroutes bezighouden er wel mee te maken krijgen. Ik heb met het bijwerken van busroutes zelf gemerkt hoe vervelend die hele korte stukje weg zijn die je pas bij ver inzoomen ziet en vaak alleen door de controlemechanismen binnen JOSM opmerkt.

Dus nodes alvast op bepaalde overgangslijnen aanbrengen… ja, en daar ga en help ik in mee.
Verdere voorschot op toekomstig gebruik van area / polygonen zou niet moeten interfereren op huidige mapping van alleen lijnelementen.

#16

Ik ben trouwens echt wel benieuwd of je een methode kunt ontwikkelen waarbij je gemakkelijk landuse-area vanuit BGT kunt kopiëren. Het goed uitlijnen van belangrijke wegen wordt door diverse mappers wel aandacht aan besteed. Uitlijning van de omliggende landuse blijft meestal liggen. Als ik het doe kan ik het niet laten om het super nauwkeurig de BGT-lijnen na te tekenen maar dat kost erg veel tijd voor een vrij onopvallend resultaat.
Zou dat met veel minder handelingen kunnen dan kunnen we qua uitlijning veel meer werk verzetten. Bijv. te beginnen met de eigen directe omgeving (zoals ik nu helemaal handmatig doe) of in grote steden of langs grote wegen. Vervolgens kan het gebied met bijna perfecte uitlijning als een olievlek uitbreiden. En met goede afspraken kunnen we het meteen goed doen zodat aanpassing pas weer nodig is als er in werkelijkheid veranderingen zijn.

Lage kwaliteit van uitlijning valt op de kaart meestal niet eens zo op. Het is pas met een luchtfoto op de achtergrond dat je het gaat zien en met BGT-belijning al helemaal.
Overal is wel landuses dat beter uitgelijnd kan worden en dat betekent dat een gerichtheid op betere uitlijning helpt om allerlei fouten, verouderingen en ontbrekende details in vooral ondergemapte gebieden te ontdekken.

#17

Je opmerking zette me aan om iets te doen wat ik al langer had willen doen, namelijk het maken van een import-voorstel voor polderwater (weliswaar een natural, maar net als de meeste landuse eigenlijk een landcover :slight_smile: )
https://forum.openstreetmap.org/viewtopic.php?pid=687335#p687335

In een multipolygoon (met hoofdzakelijk water en gras) werkt de omschreven methode goed, is mijn ervaring met handmatig overnemen van BGT-data.

Zonder multipoygoon of met veel meer wisselende landcovers wordt het denk ik wel complexer.

–
edit: correctie