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.

Hi A67-A67,

De rijstrook d.m.v. lanes is in OSM alleen zichtbaar als je in JOSM daar specifiek een visualisatie op aan zet.
Op Openstreetmap de webversie (view & edit), en in diverse navigatie apps o.b.v. OSM zie je die rijstroken niet.

Werkt goed voor een snelweg met 8 banen, waar je maar één keer de weg intekent. Maar hier zijn zoveel stromen, waardoor er diverse vreemde bochten en niet-bestaande kruizingen met de trambaan leidt alsook je een veelvoud aan restricties nodig hebt.
Te meer omdat hier ook nog een trambaan is ingetekend, wordt het geheel met rijstroken er niet duidelijk op en juist door de rijbaan van de busbaan te scheiden creëer je duidelijkheid en voor gemorotiseerd verkeer een betere visualisatie van de werkelijkheid.

Een voorbeeld daarvan is bij de kruising Middenweg / Linaeushof waar er stad in een erg bijzondere bocht gemaakt wordt, terwijl dit een flauwe bocht naar rechts is voor het eiland.

Een ander voorbeeld is bij de kruising Linaeusstraat / Wagenaarstraat de weg op de kaart maakt hier een slinger naar links omdat de lanes zijn aangegeven, maar de werkelijkheid is dat de automobilist gewoon rechtdoor rijdt.

Heb dit voor een afrit op de snelweg ook al onhandig gevonden qua visualisatie; maar dan is het tenminste een afsplitings van rijbanen. Dat is hier niet het geval en is de enige reden het wisselen tussen 'lanes' en rijbaan is omdat er geen broodje, of verhoging ligt; dit maakt het onnodig complex en ingewikkeld en zoals gezegd zijn de lanes alleen zichtbaar als je die heel specifiek zichtbaar maakt. En dat geeft bovendien hier een erg rommelig beeld omdat er zoveel verschillende stromen door elkaar liggen.

Met de rijbaan-methode bedoel ik het aangeven van de rijstroken. Die bovendien op Openstreetmap niet worden weergeven.

Hierdoor lijkt het alsof er een rijbaan gedeeld wordt met de trambaan, wat hier niet het geval is. Zouals bijvoorbeeld wel bij het Oosterpark of op de Linnaeusstraat stad uit het geval is.

En doordat je de 'lanes' aangeeft krijg je kruisingen met de trambaan die helemaal niet bestaan.

In de BGT staat de weg ook gescheiden ingetekend van de tram/busbaan. Dit in contrast met de Middenweg tussen de Hogeweg en Ringdijk.

Hoi A67-A67,

Ik snap wat je bedoelt, maar ik ben het niet met je eens. :-)

Er zijn daadwerkelijk gescheiden rijbanen, soms met een witte doorgetrokken streep en op sommige delen met een gele verhoging. En het is niet de bedoeling dat je gebruikt maakt van de busbaan om over te rijden/te keren. Zoals het eerst ingetekend stond was er bovendien regelmatig een kruising met een trambaan die er in de pratijk helemaal niet is.

Ook blijkt uit de "rijbanen-methode" nooit duidelijk of er wel of niet gekruisd mag worden vanuit een zijstraat, dit is nu velen malen duidelijker.

Alleen op het stukje tussen de Kruislaan en het Christiaan Huygensplein zou je met wat fantasie kunnen zeggen dat de rijbaan/busbaan/trambaan stad in de rijbaan delen en is er formeel geen sprake van een busbaan.

De rijbaan-methode werkt soms goed; maar hier niet en krijg je some van die lelijke (en niet kloppende) constructies zoals nu nog bij de kruising van de Middenweg en de Linnaeushof staat ingetekend.

Pas bij de Hogeweg delen trambaan en rijbaan daadwerkelijk dezelfde rijbaan en is de rijbaan-methode terecht toegepast.

Hey Njorlpinipini,
Why would you add 'capacity=1' to a parking space. It is redundant and is not being done consistently throughout the map.

Capacity is usefull for a parking lot to signify how many spaces there are; but not for each individual space.

Hi jmilot,
bicycle=designated is implicit for a cycleway and should not be used.

:-) je kunt het ook nooit goed doen hè :-)

I think that OSM is the perfect tool for building upon each other and it will correct itself out. Sometimes I reach out to someone to understand what they did, but if it is something small or long time ago; I don't bother.

Hi Alex,
Did you have a look at the other edits I made in the area? What do you think, why I added a tag # with value 0.75.

Could it be it is an obvious mistake, perhaps? I wonder... What tag would be combined with a value such as 0.75 in a change set wit #lanes....

I appreciate the quality control, but how dare I make a mistake; one that while reviewing you could have far easily have corrected right away, which would have saved both of us time which could have been spend in actually ammending and correcting the map. Time waste effectively by both of us:
- you creating a comment.
- me looking up your comment
- me looking up the node
- me sending a response
- you reading the response and responding probably again
- me having to engage in a conversation over a stupid mistake and apologising for an annoyed response
- you saying sorry / accepting my apology
- either one of us still needing to go fix the obvious mistake. Which since I am on my mobile right now after a 10 hour workday, just having the kids in bed & don't want to fire up the laptop as I don't feel like doing right away.

Thanks
Otto

Hi Ftcat,
With regards to the reservoir; this was the reason why I tagged it with a fixme. Could not validate it from imagery (as outdate) but also could not find any only reference to the project being finished.

With regards to the mapping of dams and reservoirs; the agreed way to map these globally is to map the outer line of the inundated area as much as possible. When it occurs that for extended periods of time the reservoir is not full you use the tags intermittent and/or seasonal.

With regards to the use of multipolygons:
1) it is not the purpose to minimise the amount of ways overlapping.
2) it is far complexer for people to edit (as you need knowledge of how to manage multipolygons)
3) it makes for complex items in the database. The road is now mapped as a dam and as water. which is also incorrect as the road is not a waterbody.
4) the road and the water do not touch; often there is a tunnel underneath or some part of the road is actually a bridge where the dam is more a weir type of structure.

Although I am not in favor of the usage to combine the dam as a line and the road as one; I know this is common practice. The reservoir ends at the dam and therefor shares a line with the dam and the road is actually behind the dam; or the dam is mapped as an area and the reservoir might share a line, and the road is on top of the dam.

If you want to map them together; still connect the several lines to make editing much more simple en clear what tag belongs to wath item. And to use a mulitpolygon makes it uncessarily complex to edit if there are changes to the road or the dam.

The purpose of multipolygons are to ensure that two polygons that belong to the same structure can be mapped as such. E.g. a patio in the middle of the building; or a serie of lakes that together form a landmark. e.g. "The Panama canal" you could theoratically create a multipolygon existing of the several locks on both sides of the continent, the lakes and riverways that connect the locks. They did not do it this way and only added the waterway canal as multipolygons to show that it is a series of waterways belonging to the same structure.