Gelet op wat Andries hier schrijft (ik ben er niet in Github gedoken, maar vertrouw erop dat bovenstaande klopt) heb ik een paar experimenten gedaan om ee beeld te krijgen van de opties en (on)mogelijkheden. Daarbij is het genoemde onderscheid (-A- aan te passen met een paar regels code, hetzij in Standard Carto of in een eigen rendering naar smaak obv hetzelfde VS -B- gelet op beperkingen in nu breed gebruikte technieken in ons project niet op afzienbare termijn haalbaar) naar mijn idee belangrijk is.
Het zijn zoals benoemd in de changesets experimenten en ik heb geen zin in ruzie hierover, dus als iemand een probleem ermee heeft: draai maar terug (of ik zal het op verzoek doen). Maar mooier zou zijn als er iets tussen zit waarmee we verder kunnen om tegemoet te komen aan de verschillende inzichten n als iemand voorstellen kan verbeteren/uitbouwen ipv alleen maar kritiek.
-Gaagaquaduct:
https://www.openstreetmap.org/way/303312405/history
was al area met bridge=aqueduct, met daarbij ook waterway=riverbank
met het hierboven omschreven probleem dat -kennelijk door technische beperkingen ipv te wijigen keuzen- het niet lukt om de water-area te renderen boven de bridge area
hoopte dat omzetting van waterway=riverbank naar het meer gebruikelijke natural =river verschil zou maken, maar dat deed het niet in Standard Cartp.
Opvallend: in de JOSM-weergavestyle “Mapnik (true)” worden de vlakken wel correct gerenderd, maar misschien is dat in deze JOSm-style een toevalstreffer die elders weer verkeerd uitpakt?
Cortlandaquaduct
https://www.openstreetmap.org/way/638876601/history
Was qua area (daar gaat het me nu voornamelijk om) nog een blank, zowel voor man_made als natural=water.
De bestaande water-area’s aan weerszijden versmalden dus onrealistisch omdat er alleen een lijnelement werd gerenderd
Situatie voorafgaand aan aanpassing:
heb een man_made=bridge toegevoegd, even zonder bridge=aqueduct, maar met layer 1
Daarnaast heb ik een -iets kleinere, viaduct heeft immers opstaande wanden die geen water dragen) water area toegevoegd, met layer =2 (geldt strikt genomen weer niet voor de wanden, aquaduct heeft een U-vorm met wanden die weer boven het water uitkomen…)
Hoopte dat daardoor water boven bridge kon worden gerenderd, maar helaas, nog steeds de ogenschijnlijke versmalling
**De Waterdrager **
(eveneens Ringvaart van de Zuidplaspolder, achtertuin van Peter en voor de wandel- en fietspaden denk ik een van de weinige uitzonderingen op de terechte constatering van Phicoh dat wegen onder viaducten bij ons toch altijd wel moeten zakken om onder een viaduct door te komen (de rijbaan doet dat wel, meer doorrijhoogte nodig
https://www.openstreetmap.org/way/638877699/history
*Situatie voorafgaand aan aanpassing:
*
Dit is om meerdere redenen een bijzonder geval, waarbij ook twee watervlakken onder het viaduct doorlopen.
Ondanks toevoegen van layers lijkt het geheel ten onrechte dat je vanaf de Ringvaart kan afslaan naar de kruisende wateren. Die liggen echter een paar meter lager. Snap dus heel goed de wens van sommigen duidelijk te maken dat je in een betonnen bak zit.
Heb de parallel lopende fietsbrug, die op dezelfde constructie loopt, even als apart object getekend, is al complex zat.
Heb de water-area ook bridge=aqueduct meegegeven (zodat ie te vinden is als zodanig), maar geen man_made=bridge (gelet op de eerdere resultaten). Daarnaast ook layer=1
De wand aan de zuidkant van het viaduct heb ik als aparte man_made=bridge ingetekend, eveneens layer=1
Het gerenderde resultaat is op zich wat het denk ik zou moeten zijn, maar ik vind het zelf eigenlijk te gekunsteld, slaat naar mijn idee toch iets teveel door naar een vorm van het verkeerde “tagging for the renderer”.
Had verder ook de rijbaan cutting=yes meegegeven (na lezen oorspronkelijke voorstel van Andries, vond ik op zich iets zuiverder, ook gelet op wat Peter schreef), maar hier vind ik tunnel niet *zo *verkeerd, lijkt me per saldo toch beter
-edit: heb de oude tunnel=yes weer hersteld-
Terugdraaien van deze variant kan beter handmatig ipv revert omdat ik ook andere landuseverbeteringen heb proberen door te voeren die nodig waren.
Limesaquaduct
https://www.openstreetmap.org/relation/8863128/history
Situatie voorafgaand aan aanpassing
Hier was een grote building=yes multipoly met layer=-1 over de lengte van de hele tunnelbak dat op zich onder het water door zou moeten gaan (er was een water-area), maar eroverheen werd getekend
Heb de building opgeknipt in een deel voor en na het water om de bak van het aquaduct (die een aquaduct toch definieert, ook volgend Rijkswaterstaat in de door Allroads aangehaalde link) een eigen element te geven.
Was geïnspireerd door wat ik bij aquaducten zag in het Canal du Midi (gemaakt door mappers met Duitse namen): een relatie die het aquaduct beschrijft.
Vond deze wiki met proposal:
https://wiki.openstreetmap.org/wiki/Relations/Proposed/Bridges_and_Tunnels
En heb de elementen hieraan toegevoegd, met separate barrier=wall (ook gelet op discussie keerwallen in spoortunnels) met als rol “on bridge”. De outline (man_made=bridge…) is volgens de wiki optioneel en heb ik weggelaten, dat is wat kennelijk steeds die vooralsnog onoverkomenlijke problemen geeft, en zonder geven de elementen in de relatie ook een correct totaalbeeld van het aquaduct.
Dit is persoonlijk mijn favoriete optie. De uitvoering kan ongetwijfeld worden verbeterd, maar het principe is volgens mij correct (beter dan de varaiant "Waterdrager), conform bestaand proposal in Wiki en de renderer kan er ook mee overweg: je ziet weer het water op de plek waar het feitelijk ook hoort.
En je ziet natuurlijk nog wel de streepjes om het lineare waterway-element, maar dat persoonlijk vind ik dat niet storend -vertelt dat er iets bijzonders is- en als je dat wel vindt, dan is dat nu iets wat wel technisch prima op te lossen in de Standard Carto of je eigen variant daarop.
Zou dit iets zijn om samen verder uit te werken en te verbeteren?