:-)

Hi Eggie,
Ik heb dit inhet verleden een tijdje zo gedaan; op basis van andere tagging die zo gedaan werd. Totdat iemand mij erop wees dat dit - zoals jij nu ook aangeeft, tot routerings problemen leidt. Ik heb dit toen zoveel als mogelijk gecorrigeerd; maar zal er best een aantal vergeten hebben. (deze edit is van 2 jaar geleden :-))

Geen idee hoe ik dit terug ga vinden !

Groet,
Otto

Hi Eggie,

'Closed over 1 year ago by OttoR'; ik heb hier een jaar geleden geëdited :-).
Ben nu een ander stuk Diemen aan het doen; en zal - zoals bij de andere changeset aangegeven - dit meenemen going forward. Mocht ik hier weer aan de slag gaan, zal ik het toepassen, maar om nu al m'n edits van +1 jaar terug te gaan lopen, heb ik even de motivatie niet.

Het mooie van OSM is dat met nieuwe inzichten we elkaar kunnen aanvullen. Ik kom regelmatig dingen tegen die niet kloppen of waarvoor inmiddels een andere manier van mappen voor is. (de import van 3D Shapes bijvoorbeeld; was leuk om toen heel snel landuse ingeladen te krijgen, maar klopt vaak niet (meer), of zouden ik in ieder geval nu gedetaillerder doen.

Ander voorbeeld; een paar jaar terug kende ik de BTG/AHN mogelijkheid niet; ik kom nu regelmatig stukken tegen die ik toen op basis van PDOK heb ingetekend, maar ik nu met behulp van de BGT/AHN veel nauwekeuriger kan intekenen.

Overigens dank voor het wijzen op de update voor street_side parking; de 'kleine' p vind ik nog wel een charmante oplossing.

parking_lane als attribuut voor een highway, vind ik overigens een draak van een oplossing. (Een uitzondering daargelaten)

Vriendelijke groet,
Otto

ok, helder; was niet bekend met die update.

Zal het gaan toepassen, going forward. Ben nu ergens anders bezig :-)

Hallo Eggie,
Ik vind dit voor street-side parkeren eerlijk gezegd een beetje overdreven. Je krijgt dan overal van die "P" op de kaart; suggererend dat het een parkeerterein is.

Neem als vorobeeld nu het Karel Appelhof. Daar staat nu 3 keer een P; terwijl het eigenlijk gewoon parkeervakken langs de weg zijn.

Om die reden doe ik het dus niet; maar alleen daar waar het echt een parkeerterein betreft.

Om dezelfde reden dat ik ook niet bij elk vakje "capacity=1" neerzet.

Dank Leo!
(Dat terugzetten van changesets/delen ervan toepassen is iets wat ik nog steeds niet onder de knie heb!)

Hi Leo,
Dat bedoel ik ook; vreemd dat deze wijzigingen überhaupt zijn gebeurd. Ik gebruik Go Map alleen voor die kleine wijzigingen of om een marker ergens te zetten zodat ik het op de laptop aan kan passen.

Gisteren echt alleen maar kleine wijzigingen toegepast. Een vuilnisbak, een bankje, een wild rooster. Niets verschoven en zeker geen areas aangepast 😊

Maar ik begrijp dat je de changeset teruggedraaid hebt?

Gek, ik heb alleen de treden van de trap, de ondergrond van het voetpad aangepast en de weg die ingetekend staat maar verboden is om te betreden gewijzigd naar 'disused'

Obviously this is a typo and should be source = BGT

Hoi IIVQ,
Omdat er hier nog een aantal wegen 'under construction' zijn, wellicht handig om de 'opening_date' erbij te vermelden.

Ik gebruik Overpass om de diverse plekken die under construction zijn na te lopen en op te schonen; omdat er ook best een aantal waren die al lang weer open zijn.

Groet,
Otto

Hoi IIVQ,
Excuses, de wijzigingen van het LTC zijn ook wel vrij recent :-); en ik was er inderdaad niet langsgereden afgelopen maand.

Ik probeer zoveel mogelijk wegen die al bestaan te wijzijgen of een nieuwe geometrie toe te passen middels een "Replace" zodat de historie van het object bewaard blijft. Alleen als er erg veel veranderd is, wil ik nog wel eens iets weg halen en opnieuw intekenen, omdat er dan zoveel moet gebeuren maar kan me niet voorstellen dat dit hier het geval is geweest.

De afgelopen dagen zijn er wel een aantal sync issues geweest (wrsch omdat jij iets herstelde en ik een edit deed op de oude dataset) mogelijk dat dit iets heeft aangepast?

greot,
Otto

Hallo Leo,
Dank voor de verheldering.
Ik heb via Overpass alls het goed is alle wegen 'under construction' even nagelopen en nagenoeg allemaal zijn deze voor langere tijd afgesloten én hebben ze waar ik het kon vinden een ieder geval opening_date en een verwijzing naar de webpagina van de werkzaamheden.

Een aantal constructions die geen verwijzing hadden of opening_date heb ik na onderzoek (website gemeente, gvb etc...) verwijderd.

Ikzelf gebruik OSMAnd veel en die biedt de mogelijkheid om 'live' updates op te halen, dus dan is het wel prettig als je aan het fietsen bent dat de werkzaamheden erin staan. Zal voor kortdurende werkzaamheden de conditional gaan gebruiken.

Overigens moeten die natuurlijk ook wel weer verwijderd worden indien niet meer van toepassing :-)

Groet,
Otto

?

Als Teek dezelfde user is als Hendrikklaas, dan heb ik hem gesproken en heeft hij hier met veel pijn en moeite een local survey gedaan en is bezig met micromapping. (zie ook met comment zojuist bij de changeset van een paar maanden terug door Teek bij Durgerdam).

Hij maakt zich ook zorgen over dat de BGT ingetekende lijnen niet kloppen; maar heb hem laten weten dat dit doorgaans wordt gedaan door landmeters met een RTK correctie op het GPS signaal en ik dit dus doorgaans als basis neem om pas overduidelijke fouten te corrigeren en via de PDOK Report API terug te melden.

Hij heeft bijvoorbeeld ook de wegen op het eiland weer aangepast, terwijl vanuit PDOK er een karrespoort lijkt (track), er aangelegde voetpaden zijn die ik in zou tekenen als footway en dan de paden over het gras en de dijken als path.

Maar goed, ik ben niet ter plaatse geweest :-)

Hallo Teek,
Zou je de edits een beetje op willen schonen.

De meeste meerpalen zijn nu twee keer ingetekend. Zou je dit willen opschonen?

Voor wat betreft de steigers; is het voldoende om deze in te teken als "man_made=pier"; hier hoeft geen pad overheen getekend te worden. Wat wel weer wenselijk is, is om ze aan te laten sluiten op de weg, zodat het duidelijk is dat er een verbinding is.

Als het overigens een overduidelijk voetpad is, zou ik het intekenen als footway en niet als path (olifantepaadje) en een trap ook als zodanig intekenen. (e.g. thv Dugerdammerdijk 168 lijkt een trap te zitten).

Een slipway wordt niet ingetekend als weg, maar als punt daar waar het water geraakt wordt. Meestal met een serviceroad naar het water toe, maar hier zou een track ook volstaan.

Ik zie dat je als bron PDOK en local survey aanhoud, maar gebruik ook eens de BGT en AHN lagen in JOSM om de edits uit te lijnen (zie: https://tinyurl.com/3snt792f)

Groet,
Otto

Groet,
Otto

ik heb er wet meadow van gemaakt :-)

Dag Teek,
Wordt hier een zo'n groot huis gebouwd half over het eiland / half in het water?

Ook heb je de wegstructuur aangepast; terwijl dit juist bedoeld was om onderscheid te maken tussen het karrepad, de formele wandelpaden en de olifantenpaadjes.

Tot slot weik je met de embankement af van wat er door landmeters in de BGT is gezet en wat ook op de AHN te zien is als hoogteverschil.

Groet,

Otto

Dag Eggie,
Nee inderdaad is er geen getijde, dus ook geen tidalflat; het is meer een landje wat onderloopt.
Wet meadow leek ook niet correct
Groet,
Otto

"OSM heeft geen eigen renderer": osm.org/ laad toch echt met een laag 'Standard'. En voor de gemiddelde gebruiker lijkt dat toch echt de eigen renderer van OSM. Nergens zou je hiervan afleiden dat het van een 3e partij is. Anders dan in JOSM heb ik ook geen renderer gevonden die wél rijstroken weergeeft.

Ik betwist niet het nu van het aangeven van rijstroken en snap goed het verschil tussen rijstroken en rijbanen. (ook al heb ik het jargon wellicht hierboven soms verkeerd)

Dat de wegbeheerder ervoor gekozen heeft om die scheiding soms met een doorgetrokken witte lijn aan te geven, soms met een broodje erbij, soms met een verhoging, maakt het al helemaal een rommeltje.

Kaarten maak je uiteindelijk ook voor de gebruiker en het doel zou moeten zijn om de werkelijkheid zo getrouw mogelijk weer te geven.

Komt bij dat nagenoeg geen één kaart renderer de rijstroken weergeeft. Kijk ook eens naar Google/Apple Maps, TomTom, etc.. die er hier óók voor kiezen de rijbanen opdelen in auto stad in, bus/trambaan en auto stad uit en tussen de Linnaeuskade en Hogeweg er weer één weg van maken.

Ik denk niet dat we het eens worden hier. Jij vindt dat de trambaan en busbaan altijd een rijstrook zijn en ik ben van mening dat het tussen Ring A10 en Hogeweg separate rijbanen betreffen. Dat bovendien het intekenen als rijbanen (i) duidelijker is voor de gebruikers van de kaart en (ii) dat het de ingetekende wegenstructuur simpeler en overzichtelijker houdt en je daardoor (iii) beter kunt zien waneer de weg gedeeld wordt met de trambaan en wanneer niet.

Dat een bepaalde keuze ooit is gemaakt of dat iets altijd zo gedaan is, maakt niet dat je dit kunt herzien. Of dat met het veranderen van de tijd en ander gebruik van de kaart je andere keuzes maakt. OSM van 10 jaar geleden is echt anders dan OSM van nu.

Maar ik zie ook dat wat jij zo stellig beschrijft zeker niet stuctureel wordt toegepast en dat er vaker rijbanen voor de tegengestelde richting zijn ingetekend (overigens mét rijstroken), waar je volgens jouw logica ook één weg met rijstroken kunt intekenen, alleen zou dat de kaart onduidelijker maken.

Eén van de belangrijkste use-cases van een kaart is het visualiseren van de omgeving, zodat mensen zich kunnen oriënteren. Steeds vaker ook zodat machines zich kunnen oriënteren of de combinatie van beide.

Dat zelfs de eigen redenderer van OSM rijstroken niet weergeeft en eigenlijk de meest gangbare navigatie apps dat ook niet doen, pleit ervoor om de rijbaan te scheiden. Voor een navigatie-app is het met de juiste restricties niet nodig voor de routing, maar voor een bestuurder die naar de kaart kijkt wat er van haar/hem verwacht wordt is het wel nuttige informatie.

In dit geval is er in de rijstrook voor de gangbanre weggebruiker geen tram embeded; dit geldt alleen voor de busbaan in het midden. Dat de wegbeheerder er some voor kiest om er een broodje tussen te leggen en dit op sommige stukken niet te doen maakt de visualisatie hier juist rommeliger; juist door gebruik te maken van rijstroken.

Ik denk dat OSM is uitgegroeid tot een veel veelzijdiger platform/database met veel meer use cases dan de traditionele stafkaart.

Een voorbeeld van "tagging for the renderer" zou zijn het separaat in kaart brengen van alle rijbanen op de snelweg. Dat doen we niet, omdat het hier geen toegevoegde waarde heeft om te laten zien dat er 2 of 4 rijstroken zijn en de lanes tag dit regelt voor navigatie; maar volgens jouw logica van de hartlijnvolgen, zou je hier ook één way kunnen gebruiken om zowel de heen als de terugweg middels lanes aan te geven. Hier kiezen we er toch ook voor om de separate rijbanen in te tekenen?

Weergeven waar bomen staan of waar of prullenbakken of ... zou je ook kunnen scharen oncer "tagging for the renderer"; toch wordt dit ook gedaan en geeft het visuele informatie naast dat je de database kan bevragen over deze informatie.