Aquaduct voortaan als man_made=bridge? NEE.

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 :wink:

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?

Ziet er qua opzet goed uit.

Ik denk dat dat voor draagvlak wel handig is. Alles rendert nu zo goed als dat gaat in Carto-OSM bij het Limesaquaduct, behalve die zwarte randen op de waterway. Alle ingetekende aquaducten in Nederland hebben doorgaans een water-area met daarover een waterway voor de routing. Ik vrees alleen dat er op Carto-OSM vooral vanuit de situatie waarin er geen water-area is geredeneerd gaat worden als we dit qua rendering aankaarten. Of kun je nu vanuit de stylesheet misschien ook de relatie-rollen die hij heeft oppikken?

@multimodaal Misschien omdat ik zo zo goed ken, maar Cortland-aquaduct en Waterdrager zien er helemaal niet realistisch uit, ik herken ze ook niet aan de weergave alleen maar aan de namen! Bij lagere zoom wordt het Cortland aquaduct beter, maar de Waterdrager nog minder.

Zonder zicht op betere rendering zou ik het zo niet doen!

https://github.com/gravitystorm/openstreetmap-carto/issues/3485

Twee vragen over de combinatie.

Dan zou er een uitzondering gemaakt worden op de regel dat je kruisende ways die ongelijkvloers zijn geen gemeenschappelijke nodes moet geven. Dit voorstel lijkt me daarom onwerkbaar en kansloos.

Dit lijkt me de beste en meest realistische oplossing. Dan hoeft bridge=aqueduct ook niet meer op het lijnelement doordat het voor routering gedetecteerd kan worden door gedeelde nodes met de area of voor de zekerheid met een node met bridge=aqueduct.

Belangrijk en misschien cruciaal minpunt: door op deze wijze het bouwwerk aquaduct en het water erboven gezamenlijk aan te geven valt het water niet onder een key natural maar onder de key man_made…

@multimodaal
De tag man_made=bridge rendert een vlak boven andere vlakken zoals water. Daar veranderen bijkomende tags niets aan.

Uiteraard, heb ik mij deze zaken ook afgevraagd, dat dit een tegendraads tagging zou zijn.
Het is wel zo dat de kruisende wegen highway niet met elkaar in verbinding staan. Alleen de man_made.
De versteviging van het aquaduct (zo ook viaduct) bevindt zich ook altijd een layer lager.

De zoektocht naar oplossingen.

Het plaatsen van de node waar men er onder door gaat op de juiste plaats.

Het renderen van natural=water onder de man_made=bridge, herkent men dus als een problematiek.
Nu het vervolg afwachten.

Ik heb het gaag viaduct aangepast, de outline is altijd breder dan het water is.
Daar loopt soms een looppad over of staat een reling, barrier fence area. en andere varianten

Hier bijvoorbeeld: https://www.openstreetmap.org/#map=19/53.18498/5.81921

Een bankje, wandelpaden, beplanting, en aan de andere kant een fietspad.

–achterhaald–

Zelf vind ik deze zoals gezegd ook niet ideaal.
Maar ben wel benieuwd naar jouw bezwaren als kenner specifiek tegen de rendering van de Waterdrager.
Persoonlijk vind ik daar namelijk de rendering wel goed, alleen de -door mijzelf gebruikte- constructie (elementen + tagging) te gekunsteld, namelijk het muurtje aan de zuidkant als aparte bridge (aan noordkant is door fietspad misschien nog wel iets voor te zeggen)

**Voor aanpassing
**

Na aanpassing

Foto’s voor de mensen die niet om de hoek wonen:
https://forum.openstreetmap.org/viewtopic.php?pid=722759#p722759

Luchtfoto:
https://openkaart.net/kano/#map=18/51.96633/4.61578&layers=A&overlays=sea,lpn

Wat voor mij het grootste bezwaar tegen de oude rendering was, was dat het voor de gebruiker op geen enkele manier duidelijk was dat je over zo’n lang stuk over het luchtledige vaart (of onder het water loopt als je de paden/wegen wegen kruist). Het meest opvallende foute gevolg daarvan is dat het lijkt alsof je voor en na de blauwe tekst “Ringvaart van de Zuidplaspolder” vanaf de vaart naar links of rechts zou kunnen afslaan naar de sloten naar aan weerszijden, Dat kan echter helemaal niet, want die dwarssloten liggen zo’n 5 (?) meter lager en kruisen onder het viaduct.

Ik ken de situatie vanuit wegperspectief niet zo goed. Wat me nu wel opvalt is het verschil in lengte van de tunnel op de rijbaan.
Aanvankelijk had ik die, in lijn met initieel voorstel van Andries, naar cutting=yes gezet ipv oude tunnel=yes, en daarom ook langer gemaakt, daar waar de weg begint te zakken. Bij terugzetten naar tunnel is lengte niet opnieuw verkleind, kan natuurlijk wel.

Knelt daar de schoen wat betreft geen goede weergave van de situatie voor jou, of zit dat elders?

Over relatie-variant zoals bij Limesaquaduct, onderaan op https://forum.openstreetmap.org/viewtopic.php?pid=722901#p722901

Da’s inderdaad een goeie.
In overpass is selecteren op wel/gen lid van een bepaald type geen probleem.
Opencyclemap doet dat ook in de renderering en lijkt -voor mij als relatieve leek- op zelfde techniek als de Standard Carto te draaien (een Mapnik style in CartoCSS, en met zelfde ‘peetvader’):
https://www.opencyclemap.org/about/
https://github.com/gravitystorm/openstreetmap-carto

In gewone mensentaal zou de renderingsregel dan bijvoorbeeld kunnen zijn (niet gehinderd door kennis op dit gebied):

-Indien een [way] mey [waterway=*] GEEN lid is van een relatie van [bridge=aqueduct] :
*render de waterway dan zoals nu (dus met lijntjes eromheen en naam van de waterway erop)

-Indien een [way] mey [waterway=*] WEL lid is van een relatie van [type=bridge] EN [bridge=aqueduct] :
*render de waterway dan *zonder *lijntjes en *zonder * [name] van de waterway
*render de [name] van de [type=bridge] relatie

Iemand met verstand van zaken die daar misschien wat inzicht in kan geven?

De dwarswaters zijn nu goed. Die tunnel is inderdaad (veel) te lang! cutting is het niet, dat is voor als de weg plat rechtdoorgaat door een uitsnijding in verhoogd land. Mogelijk dat dat leuk rendert, maar zover zou ik niet willen gaan.
Een tunnel is het voor de auto’s ook niet, trouwens, je zou het wel wel een korte tunnelbak unnen noemen vanwege de betonnen randen maar als je er een dak op zou leggen komt er niks meer onderdoor. Het aquadukt gaat er op veel hogere palen overheen. De fietsers en wandelaars gaan trouwens buiten de betonrand onder het aquaduct door, die zakken ook niet.
Dus eigenlijk vind ik tunnel hier helemaal niet van toepassing, het is gewoon een weg die al laag ligt maar nog een een heel klein beetje zakt tbv bussen en vrachtauto’s. Je zou hooguit de betonnen randen apart kunnen taggen.

Bij inzoomen https://www.openstreetmap.org/#map=19/51.96613/4.61600 ziet de waterweg er niet uit met die strepen in het midden die de waterway bridge aangeven, en de onderdoorgaande weg loopt gewoon van twee kanten in het water tot aan de strepen. Dat geldt ook voor het kruisende wandelpad (Jezuspad?) en het fietspad, beiderzijds.

Het fietspad over de smalle brug naast het aquaduct ziet er ook vreemd uit, het is een dikke streep ipv een brug met een pad. In feite loopt het fietspad direkt naast het water, niet over een aparte fietsbrug.

Desondanks is het in totaal niet slecht, maar het lijkt me nog niet het eindresultaat dat je zou willen zien.

Er spelen een aantal zaken door elkaar heen.

  1. Het gebruik van man_made=bridge, is een voorgeschreven basistag.

wiki zegt dat je dan ook bridge= mag gebruiken.

  1. De rendering van natural=water over man_made=bridge.

  2. Het gemis van een goede rendering van de weg onder het aquaduct, tunnel=yes kan niet, te onvolledig.

  3. Het gemis van rendering van area:highway= dan zou dan over de man_made=bridge gerendeerd moeten worden. (nu bridge gebruikt terwijl het een onderdeel van het aqueduct is)

  4. Rendering van waterway bridge= zijlijnen. Dat zou bij bridge=aqueduct een blauwige kleur kunnen zijn, of bij man_made niet gerendeerd.

Deze problemen zijn identiek aan viaduct problemen. Welke we nog niet zo onderkennen vanwege het feit dat we nog niet veel area:highway tagging en aan rendering doen.
area:highway mag je vergelijken met natural=water, wat eigenlijk area:natural=water is of het meer area:waterway=

Dan kom je bij het punt van area:waterway= en mogelijk gebruik van dezelfde kleuren.
Eigenlijk wil je niet nieuwe tags ontwikkelen.

Deze diskussie lijkt een beetje vast te lopen.

Ik heb het even bij mezelf laten bezinken en zojuist alles nagelezen. Enkele punten:

  1. Ik ben ervoor om het verschil tussen tunnel en niet-tunnel op te lossen door elke onderdoor-constructie gewoon als tunnel te taggen. De definitie van tunnel wordt dan een beetje opgerekt, het betekent niet meer dan dat je ergens onderdoor gaat. Je zou nog kunnen onderscheiden tunnel=yes voor een echte tunnel en tunnel=[???] voor iets wat de een een tunnel(tje) noemt en de ander niet, maar eerlijk gezegd denk ik niet dat dat erg nuttig is, gezien de grote variatie in constructies en de variatie in betitelingen voor hetzelfde ding, ook afhankelijk van de doelgroep: Iets wat voor een auto een brug over een tunnelbak is, is voor een fietser of voetganger al gauw een tunnel.

Wat betreft de rendering hoeft er denk ik ook geen verschil te zijn.
Je sluit dan gewoon aan bij de volksmond, die vanaf de weg elk onderdoortje rustig een tunnel(tje) noemt.

  1. De kwestie van dubbel taggen: MI is er geen daadwerkelijk probleem met het taggen van zowel tunnel (op de onderdoorgaande weg) als bridge op de waterweg en/of de aqueduct area. Je kijkt naar de weg om te bepalen of je daar tunnel op wil taggen, je kijkt naar de waterweg om te bepalen of je daar bridge op wil taggen, hetzij als area hetzij als way.

  2. De rendering. Het voornaamste probleem is de rendering (in OSM carto) van de waterway, die wijkt aanzienlijk af van de feitelijke area. Dus als je zowel de aqueduct area tagt als de waterway, dan krijg je een “zwemmende” waterbrug met “zwemmende” randen. Bovendien lopen de onderdoorwegen in het water tot aan de waterway, dus tot aan de zwemmende brugranden. Zelfs als je de weg als tunnel getagd hebt.
    Dit probleem is alleen zichtbaar als je ver inzoomt, maar dat betekent wel dat als je aan het routeren bent, zeker voor fietsen en lopen, dan krijg je het altijd te zien, omdat je dan ver inzoomt.

Mijn konklusie is (zoals anderen al gezegd hebben) dat er vooral een renderingprobleem is. Het renderen moet natuurlijk door/via de renderer worden opgelost, maar je moet wel zorgen dat de tagging zodanig is dat het gerenderd kan worden.

EDIT: In feite dus vrijwel zoals OP al voorstelde! Ik had er alleen wat langer voor nodig om zover te komen…

De vraag is: hebben we nu een afspraak/voorstel voor tagging wat voor de renderer werkbaar is zonder ingewikkelde processing?
Hebben we eigenlijk precies duidelijk hoe we het gerenderd zouden willen hebben?

BUMP!
Ik kwam laatst weer langs die github-melding, omdat ik weer met de waterdrager in Nieuwerkerk aan de IJssel bezig was. De huidige rendering krijg je met geen enkele tagging goed. Als je een water=* area tagt, komt het in een speciale renderlaag die niet combineert met man_made=bridge.

Wat ik begrijp is dat het wel mogelijk is om een vlak met de kombinatie man_made=bridge en bridge=aqueduct met een waterkleurtje te renderen.

Dat is een oplossing, als er tenminste geen andere elementen over datzelfde vlak lopen.

Maar dat is dus vrij simpel te doen, en ook best wel logisch. Het fietspad langs het water over de waterdrager loopt nu over dezelfde bridge. Het enige wat je hoeft te doen is het bridge-vlak splitsen zodat het een watergedeelte heeft en een gewoon bridgegedeelte. De ene waar de waterway over loopt tag je dan bij met bridge=aqueduct en de andere niet. Ze mogen gewoon tegen elkaar aanliggen, voor zover ik het begrepen heb.

Dat is vergelijkbaar met hoe je een way knipt als er een eigenschap speciaal voor dat stukje geldt.

*NB: Is dit taggen voor de renderer? Vind ik niet. De aanleiding is een rendermoeilijkheid bij de huidige tagging. Je taggingschema daaraan aanpassen is taggen voor de renderbaarheid, dat is toch anders. *

Peter,
Het in de langs richting knippen van een kunstwerk of bouwwerk voor niet civilisten, lijkt op het niet gewenste opknippen van panden. Een brug of bouwwerk is een ondeelbaar geheel waar altijd een derde onzichtbare maar verlichte weg doorloopt. De wiettelers wisten die maar al goed te vinden.
De strijd met de oude regels van OSM zal nog wel even voortduren en zonder grote schoonmaak en aanpassingen van de oude regels blijft t lapwerk. De eerste mappers/ontwerper of programmeurs konden met geen mogelijkheid inschatten welke groei OSM door kon of zou maken en tot welke detailleringen dat zou leiden. Maar ze bouwden een knap en strak lijnen systeem. Andy antwoordde op mijn vraag “waarom staan er zo weinig of geen bruggen in OSM, het zijn tenslotte soms onafzienbare bouwwerken”, kwam hij terug met de verwijzing naar bridge=yes. IMHO een armoedig antwoord, wat geen uitkomst biedt, maar wel de kool en de geit spaart, de onderbouwing was dat een bouwwerk als een brug, viaduct of aquaduct niet als bouwwerk getagged kon gaan worden, wegens de al eerdergenoemde oude beginselen ?

Tja, we noemen het bij wegen “opknippen” maar je knipt de weg niet echt, je zet alleen een punt waarbij je aan de ene kant een andere eigenschap zet dan aan de andere kant. Maar het blijft diezelfde weg. Je knipt geen brug aan stukken, je deelt hem ook niet echt, je zet er een streep op en aan de ene kant is-ie voor het water en aan de andere kant voor iets anders. Net als in werkelijkheid dus.

Als een brug echt alleen water doet, dus puur aqueduct, hoeft er nix gedeeld te worden. Het Ringvaartaquaduct over de A20 heb je dan te pakken, want weliswaar loopt er ook een weg naast, maar die heeft zijn eigen viaduct. Het rust dacht ik wel op dezelfde ondersteuning, maar heeft zijn eigen overspanning. Het Gouwe-aquaduct over de A12/A20 heeft zelfs aan beide kanten een apart viaduct.

Maar even over het basisidee: man_made=bridge+bridge=aqueduct blauw kleuren, liefst met kontrastlijntjes aan de zijkanten, en dan de waterway zónder lijntjes erop zodat je hem niet ziet. Werkbaar?

Hoe kleur ik dit kleinste aquaductje van Nederland blauw?
https://www.openstreetmap.org/way/824347029

Peter, hoe graag ik ook met je mee ga, maar het lijkt op taggen voor de renderer, met layers maak je de render volgorde duidelijk, dat de renderer daar niets mee doet, tja eigenwijzigheid, maar daar mag ik geen moeite mee hebben.
Maar je kan een brug eigenlijk niet inbrengen zonder het maaiveld principe te verstoren. Je brengt niet de niet de steunpunten en de liggers in, maar het daarop liggende brugdek, middels man made bridge. Weinigen zullen dan ook de zichtbare landhoofden mee nemen, die bij een lokale survey wel zicht- en meetbaar zijn.
Je idee is trouwens wel aardig voor de kijkertjes met blauwe ogen ;_)

Nee, dat klopt niet! De tagging is man_made=bridge + bridge=aqueduct(+layer=1) dat blijft zo. Het is ook niet mijn idee, het komt als suggestie van een osm Carto bijdrager, in een github issue. Is dus geen tagging voor de renderer, maar anders renderen van wat iets al getagd is.

Ik zie niet goed hoe het maaiveld hierbij een rol speelt? In de github-issue ging het wel over watervlakken ten opzichte van brugdekken, maar het bovenvlak van man_made=bridge+bridge=aqueduct blauw te maken heb je daar volgens die persoon juist niet mee te maken. De vraag is alleen: geeft deze weergave het bedoelde visuele effect en verknalt het niet iets anders.