April loopt op z’n einde. Dat betekent dat het tijd is voor de volgende provincie-van-de-maand: Groningen! Het plan is dat iedereen mapt wat hij/zij belangrijk of interessant vindt, en daarbij kunnen we samenwerken, nuttige info delen en onze voortgang laten zien.
Dan hier een eerste aandachtspunt in Stad Groningen.
Daar heeft een zojuist startende mapper de routering aangepast door de tijdelijke wegen te verwijderen.
Ik heb even geen idee of het klopt en wat de consequenties zijn.
Wellicht weet iemand van de hoed en de rand?
We hadden hier besproken dat tijdelijke wegen die al verdwijnen soms moeten blijven bestaan, omdat de routering anders lange tijd kapot is als je met een oude snapshot werkt.
Op deze manier ontstaat er inderdaad een gat in de routering terwijl deze relaties slechts een paar maanden (of zelfs weken) niet beschikbaar zijn. Om genoemde redenen lijkt me dat onwenselijk.
Aangezien de tijdelijke Julianabrug inderdaad is verdwenen en niet meer zal terugkeren is het verwijderen mijns inziens verdedigbaar, maar dan moet de nieuwe brug inclusief nieuw knooppunt en verdiepte ligging wél worden ingetekend (met conditional restrictions) zodat de routering blijft werken.
Eigenlijk zou dat persoonlijk mijn voorkeur hebben boven het laten staan van de oude situatie tot september. Liever een kaart die (op het oog) nog niet klopt maar wel gaat kloppen, dan een kaart die niet meer klopt en ook nooit meer zal kloppen. En door middel van conditional restrictions is de werkelijke beschikbaarheid van de verschillende relaties toch heel precies te verwerken.
Hallo allemaal. Ik was die onwetende newbie. Het viel mij dus op dat de brug en de verbindingen daarop fysiek al verwijderd zijn. En in plaats van te denken 'waarom is dat niet bijgewerkt ’ dacht ik, laat ik zelf eens een bijdrage leveren.
Ik snap (hoewel ik niet weet hoe het exact werkt, is daar ergens generieke documentatie over/ richtlijnen) het argument van kaart routering, maar vind het anderzijds ook wat gek om niet meer bestaande en ook niet terugkomende wegen te laten staan. Ik ben zelf een fervent gebruiker van osm als ik ergens naar toe ga om de situatie ter plekke te bekijken. Ik zou er persoonlijk niet vrolijk van worden als de tijdelijke relatie assen-groningen over de tijdelijke brug ingetekend staat maar er niet meer is. Ook al omdat de nieuwe relaties feitelijk al fysiek bestaan en ook op de kaart zijn ingetekend… Ik wend me over het algemeen tot osm met het idee daar vooral de feitelijke situatie te zien.
Anyway, geenszins de bedoeling om hier een discussie te herstarten die vast al vaker is gevoerd, maar wel ter toelichting van de ‘boosdoener’.
Tot slot, klopt het dan ook dat per volgend weekend , als de beide definitieve bogen Assen - Drachten en Drachten - Assen open zijn, de boel wel aangepast kan?
Welkom op OSM en op het forum, tjjho. Ik wens je veel plezier toe met mappen.
De beweegreden voor je wijziging is absoluut begrijpelijk. Hieronder voor de volledigheid een samenvatting van het probleem, al zal dat misschien oud nieuws zijn.
Omdat veel OSM-gebruikers en -afnemers hun brondata niet constant bijwerken, maar slechts eens per zoveel weken / maanden, is het belangrijk dat er geen gaten vallen in de basiskaart. Dit omwille van het kaartbeeld (bijv. als OSM als achtergrondkaart wordt gebruikt) maar ook de routering (bijv. navigatiesystemen). (Hyper)actuele wijzigingen zoals de verkeerssituatie en tijdelijke afsluitingen kan men uit andere bronnen halen (zoals Melvin). De basislaag van OSM is daar niet voor bedoeld (al kunnen we met conditional restrictions geplande afsluitingen wel opnemen).
Hoewel het jouw bedoeling niet was een tijdelijke situatie te mappen (de tijdelijke Julianabrug is immers permanent verwijderd), was het effect wel hetzelfde: het maakte navigeren richting Drachten onmogelijk, terwijl dat in werkelijkheid slechts tijdelijk het geval is.
Ik heb inmiddels geprobeerd er wat van te maken (changeset 150723222). Met behoud van jouw wijziging is er, om de routering intact te laten, in mijn ogen geen andere mogelijkheid dan het nieuwe knooppunt van construction af te halen en te voorzien van de juiste conditional access restrictions. De verbinding Assen → Hoogezand heb ik vooralsnog gelaten voor wat het is, aangezien die deze week nog open is en (ongeveer) op z’n oude plek ligt. Ook de verdiepte ligging staat nog op construction. Als de het tijdelijke viaduct van de ring-zuid volgende week definitief buiten gebruik is, kan in mijn ogen de verdiepte ligging van construction af. Feedback is welkom!
Volgens mij is dit een elegante oplossing voor het Julianaplein (twee gedeeltelijk geopende Julianapleinen door elkaar heen was verwarrend) maar het tijdelijk viaduct zou ik pas door de tunnel vervangen op het moment dat de tunnel echt opent. Gebruikers houden er doorgaans rekening mee dat de kaart kan achterlopen, maar niet met vooruitlopen. En het verleden is ook beter verifieerbaar dan de toekomst.
Ik heb ontbrekende ref:IFOPT tags in het OV concessiegebied ‘Groningen-Drenthe’ aangevuld. Vervolgens wil ik de busroutes in osm vergelijken met de NeTeX data van het NDOV loket. Het eerste resultaat is dat 52 van de 216 routes exact overeen komen met de NeTeX data. Dat betekent niet dat alle andere routes fout zijn. En typefoutje in de ref:IFOPT tag van een uitstaphalte zorgt al voor een afwijking bij alle routes die eindigen op het betreffende busstation.
Het is mij bekend dat er ook een project loopt om te proberen om deze controle op basis van GTFS gegevens te doen. GTFS is echter een oudere ‘standaard’ die in Nederland en waarschijnlijk de meeste europese landen wordt vervangen door NeTex. De vraag is dus hoelang GTFS nog ondersteund wordt door de OV bedrijven. Ook heb ik de indruk dat de kwaliteit van de GTFS data in Nederland onder doet voor de kwaliteit van de NeTeX data.
total :: missing maxspeed: 2569, total: 32521, pct with maxspeed: 92.1
Met 92.1% boven de 91.5 / 88.5 / 89.0 / 83.0% voor de vorige provincies en het hoogste percentage al gedaan. Met 2569 wegen het minst aantal wegen zonder maxspeed, voor de vorige provincies was dat 3168 / 2980 / 5669 / 18328.
Grafisch ziet het er zo uit:
Groningen bestaat nog uit 10 gemeentes, het lijkt erop alsof Het Hogeland en het Westerkwartier zo goed als gedaan zijn.
Ik heb vannacht zo’n 2500 building=yes omgezet naar iets specifiekers in de gemeente Groningen. Dat is ~5% van alle building=yes in gemeente Groningen, wat op zijn beurt nog geen 1% is van het totaal in Nederland.
Met wat toewijding krijgen we maxspeed=* compleet in NL in dit of volgend jaar, maar van building=yes zijn we nog lang niet af.
Zijn er hele makkelijke omzettingen bij die je (bijna) met je ogen dicht kan doen? Kerken of scholen of zo? Die zou je dan op naam kunnen zoeken en in razend tempo wegwerken.
Ik ben bang dat de meeste building=yes panden schuurtjes of garages zijn. In de BAG staan geen gebouwtypes voor panden. Alleen bij verblijfsobjecten binnen een pand staat een type. Alles zonder verblijfsobject krijgt daarom vanuit de BAG import building=yes.
Ik ben een groot voorstander van grootschalig werken, maar zoals Gertjan zegt is bijna alles een garage of schuurtje, met hier en daar een school, vergeten huis, transformatorhuisje of boerderijschuur. Met de PDOK luchtfoto en de BGT Omtrekgericht in JOSM heb je al een snelle workflow, maar heel veel sneller dan dat kun je het denk ik niet maken.
Ik hoop dat we nog aan grootschalige edits met surface=* toekomen, maar daar heb ik me nog niet in verdiept.
Wat is dan de grens? Moet je snelwegen die over 10 jaar af zijn ook maar vast intekenen?
Sommige “offline” apps (zoals bijvoorbeeld OSMAND) kunnen hun kaarten elk uur bijwerken.
Door het gebruik van access:conditional=no dacht ik (door een visuele blik op de net bijgwerkte osmand, en op opensteetmap) dat de ringweg zuid open was, terwijl deze nog zeker 3 maand dichtblijft.
total :: missing maxspeed: 119, total: 32322, pct with maxspeed: 99.6
Qua percentages goed maar ik weet niet of het aan mij ligt maar hoe meer provincies hoe meer inconsistenties ik lijk tegen te komen, de gemeente Oldambt krijgt wat dat betreft de hoofdprijs.
Wil je trouwens een overpass query doen voor de hele provincie dan werkt Groningen niet, je kijgt dan de stad Groningen, niet de gemeente/provincie.
Wat voor de provincie werkt:
[out:xml][timeout:90];
// fetch area “Provincie Groningen” to search in
area(3600047826);
(
way(area)[highway~"(unclassified|residential"][!maxspeed];
);
(._;>;);
out meta;
Ik duf niet te zeggen of dit 1 baan is of 2. Misschien heeft iemand die meer bekend is met lanes tagging hier een mening over. lane_markings=no lijkt me hier wel van toepassing.
Algemeen, men hinkt op twee gedachten.
Wel of geen lane tagging of het nu 1,2, of meerdere zijn.
Ik tag hier vooralsnog geen lanes, omdat er geen rijstroken zijn.
