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.

Hi ficat; I see it on open top map; and here it is also drawn as a very straight line; but the height lines are far less straight and doing bend and curves. Wouldn't it make more sense for the ridge to follow the height lines?

Hoi smootheFiets,
Dat ligt eraan, als de omgeving nog afgebouwd wordt dan zou je de construction kunnen laten staan of in ieder geval aanpassen naar de nieuwe contour. Is alles afgerond, dan kan dit weg. Ik ben hier al even niet meer geweest; dus kan hier niets zinnigs over zeggen :-)
Groet,
Otto

Clearly this is a mistake from splitting the one way sections.

I have corrected this now; but since it was an edit from 12 months ago. It would have been perfectly fine for you to correct this instead.

Thanks for the review :-)

Hallo Marco,
Ah! Dat is inderdaad een betere omschrijving!

Ik weet ook de exacte functie niet; vaak is het of een drinkwater pomp; of juist een riool water pomp. Maar het staat er doorgaans niet bijvermeld en de BGT Symbolen geeft op een lager zoomniveau geen icoon die de functie verklaard.

groet

Otto

ok, dank; ik zal ze ongedaan maken.

Dag Leo,
Wellicht heb ik de relatie niet goed gedaan, maar wat er nu staat klopt ook niet.
Het voorplein staat nu gemarkeerd als gebouw, het gebouw op de begane grond is nu de inner circle. De verdieping erboven (die groter is) staat niet meer ingetekend.

Uiteraard is de BAG de bron voor gebouwen, overigens komt de BGT hier heel behoorlijk overeen, en geeft bovendien meer detail, zoals dat de voetprint op de begande grond kleiner is dan de voetprint op de 1e verdieping.

Overigens kan ik je melden dat de BGT in Diemen vaak beter klopt dat de BAG, omdat ik hier woon kan ik vaak ook irl de omtrek van de gebouwen verifieren en dan is de BAG gewoon niet up-to-date en soms zelfs ronduit fout. (ook voor gebouwen die er al >30 jaar staan)