Aquaduct voortaan als man_made=bridge? NEE.

@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.

Waar we het eigenlijk over hebben is het vlakprobleem. Kan je bij een vlak bepalen, welke zijde van de omtreklijn een andere kleur krijgt bij rendering. Simpel, denk het niet.

Bij highway is er het lijn principe, maar ook het vlak principe, area:highway=secondary of area:highway=cycleway area:highway=shoulder, wat ook op de man_made=bridge kan worden gelegd.

Nu wil je eigenlijk area:waterway=aquaduct of canal in blauw gevisualiseerd hebben.
Zodat het grijs van de man_made=bridge aan de zijkant zichtbaar blijft, immers daar is geen water.

Met de huidige benaming voor het water is het schijnbaar heel moeilijk om het goed gestapeld te krijgen in de rendering.
Met een ander tag zou men het misschien beter kunnen inpassen.

Nauwelijks gebruikt:
https://taginfo.openstreetmap.org/keys/area:waterway
Normaal hebben we zo’n tag niet nodig, wellicht dat het hier uitkomst bied.

Ik heb de indruk dat we het te moeilijk maken. Het is toch volstrekt redelijk om een aquaduct blauw te maken met zijlijntjes? En eventueel een ecoduct groen met zijlijntjes, een railviaduct dat slappe lilakleurtje met zijlijntjes, een gewoon viaduct grijs. Je weet precies welk vlak het voor geldt.

Allroads, bedoel je: welke twee kanten zijn de zijkanten die de kantlijntjes moeten krijgen? Dat leek in de github issue geen probleem te vormen, De layerinfo en de wegen geven dat aan (nodes aan het vlak vast met een waterway ertussen geven aan wat de doorstroomrichting is. Als dat lastig is, kan je de info ook in een tag opnemen, of de zijkanten bijtaggen met bridge_side=yes of zo.