Renderen van tree_row

Libero · 2018-04-05T08:12:45.000Z

Peter Elderson:

Wat mij betreft zou het handig zijn als je dan een secundaire key tree_row=… had waarmee je de gemiddelde afstand in m tussen de bomen kan aanduiden, of “free” en in dat geval rendert elke node op die tree_row als een boom. Als de renderer daar geen zin in heeft blijft het een standaard tree_row.
Is dit een proposal waard?

Ja, mwa ik weet niet. Ik bedoel, als je bijvoorbeeld die secundaire key “free” hebt, dan klopt het weer niet met de werkelijkheid. En wat nu als je een rechte lijn trekt? Dan krijg je dus op het begin en eind een boomicoontje.
Op de kaart ziet de natural=tree_row er misschien wel uit als een viltstiftstreep, daar ben ik het mee eens, iets dunner zou misschien niet verkeerd zijn.

Voor houtwallen vind ik de tree_row tag hartstikke handig, je hoeft niet al die bomen afzonderlijk erop te zetten, en het is naar mijn mening de meest simpele en duidelijke manier om aan te geven dat er daar een rij bomen staat.
Je krijgt niet een kaart die vol staat met allemaal afzonderlijke bomen.

Bij Lange Voorhout ziet het er inderdaad wat druk uit, maar in het gebied waar veel houtwallen staan vind ik het dan wel weer goed passen.

Peter Elderson:

Zou het niet mogelijk zijn om een tree_row te renderen als een dunne of zelfs onzichtbare lijn waarbij elke node op de way een boomachtig rondje wordt (naar de smaak, ik bedoel stijl, van de renderer)? Dan kan je net zo precies of globaal mappen als je wil. De bomen staan dan op de aldaar heersende ondergrond. Kan je ook ronde en klaverbladvormige tree_rows mappen.

Dat zou een manier zijn om alle bomen te mappen zonder elk afzonderlijk te hoeven taggen.

Op zich is dit best een goed idee in stedelijke gebieden bijvoorbeeld. Maar voor een houtwal voldoet de huidige viltstiftstreep naar mijn mening prima.

'T is best een lastig geval trouwens, die tree_rows…
Maar ik ben wel van: houd het simpel. Hoe ingewikkelder dingen worden (als in: meerdere tags voor in wezen een tree_row) hoe lastiger het wordt om te bepalen wanneer en waar je die tags gebruikt. Dan denk ik dat je houtwallen beter kan taggen met tree_row en voor die boompjes die op een rij staan daarginds bij Lange Voorhout een nieuwe tag in het leven roept die puur gebruikt wordt voor het taggen van boomrijen in steden/bebouwd gebied.

marczoutendijk · 2018-04-05T08:57:46.000Z

/off-topic/
Het was klaarblijkelijk nog niemand opgevallen dat de Amerikaanse Ambassade al sinds januari ook niet meer op het Lange Voorhout zit!
Aangepast.
/off-topic/

marczoutendijk · 2018-04-05T09:09:42.000Z

Peter Elderson:

[…]
Als je er eenmaal op let merk je hoeveel bomenrijen er zijn, en velden waar de bomen in meerdere rijen in slagorde opgesteld staan. Dat kan stukken beter

Zeker kan dat beter, maar daar moet je niet nog een tag bij verzinnen die de afstand tussen die bomen aangeeft. Als dat een belangrijk onderdeel van een bomengroep is (omdat ze bv. geordend zijn volgens de reeks van Fibonacci), dan kun je alsnog individuele bomen gaan taggen.

Als OSMcarto een voetpad als stippellijn kan renderen, dan moet het toch niet moeilijk zijn om een tree-row als een serie groene stippen van wat groter formaat en met wat meer tussenruimte af te beelden.
Als @Math1985 nog meeleest: kun jij daar nog iets zinnigs over zeggen?

Edit: ik heb op Github gevraagd naar de stand van zaken met verwijzing naar de situatie hier.

Peter_Elderson · 2018-04-05T11:05:12.000Z

Ik heb het Lange Voorhout lopend gemapillary’d, leek me verhelderend. Excuus voor de beroerde foto’s, ik loop kennelijk nogal dronken…
https://www.mapillary.com/map/im/U5d-U9GMoMolG6-_7wFCWg

De bomenrijen zijn er, maar het zijn er wel veel en in allerlei richtingen. Nu zijn niet alle bomenrijen getekend, en zelfs als je dat doet mis je nog een hele serie verspreid staande bomen.

Het gebouw van de Amerikaanse ambassade wordt sinds een paar weken geleden leeggehaald, het verplaatsbare politiepostje was een paar weken daarvoor ineens verdwenen, en de zware hoge hekken zijn ook net weg. Kennelijk was er toch nog wel wat achtergebleven en is dat net pas weggehaald.

Peter_Elderson · 2018-04-05T13:53:26.000Z

SubieLibero:

Peter Elderson:

Wat mij betreft zou het handig zijn als je dan een secundaire key tree_row=… had waarmee je de gemiddelde afstand in m tussen de bomen kan aanduiden, of “free” en in dat geval rendert elke node op die tree_row als een boom. Als de renderer daar geen zin in heeft blijft het een standaard tree_row.
Is dit een proposal waard?

Ja, mwa ik weet niet. Ik bedoel, als je bijvoorbeeld die secundaire key “free” hebt, dan klopt het weer niet met de werkelijkheid.

Juist wel, je trekt de lijn van exact de eerste boom naar exact de laatste boom, en tussenin plaats je voor elke boom een node exact op de goede plek. Zonder verdere tagging worden die nodes dan als afzonderlijke boomikoontjes in de bomenrij gerenderd.

En wat nu als je een rechte lijn trekt? Dan krijg je dus op het begin en eind een boomicoontje.

Als je 6 Km bomenrij regelmatige bomenrij intekent dan zet je de way van eerste naar laatste boom, je meet of schat de gemiddelde afstand (heb ik bij mij thuis voor de deur gedaan, kostte me wel 20 sekonden om het op 15 m te schatten) en dat is dan je afstand (de tag hoeft geen tree_row= te zijn, er is vast wel een bestaande tag die je hiervoor kan gebruiken). De rendering geeft dan niet exact de boomlokaties weer, maar wel een realistische indikatie van de spreiding.

Op de kaart ziet de natural=tree_row er misschien wel uit als een viltstiftstreep, daar ben ik het mee eens, iets dunner zou misschien niet verkeerd zijn.

Eerder in deze draad hadden we het ArcGis voorbeeld, boomachtige wolkjes op een standaardafstand van elkaar, verbonden met een dunne lijn. Dat zou je als standaard kunnen gebruiken, zit er netjes uit en niet overheersend.
Als je een heel korte tussenruimte zou aangeven dan gaan de wolkjes overlappen, precies wat je voor je houtwal nodig hebt. Ellenlange populierenrijen langs de snelweg zou je juist ruimer spatiëren, lijkt mij, voor een realistischer indruk.

Voor houtwallen vind ik de tree_row tag hartstikke handig, je hoeft niet al die bomen afzonderlijk erop te zetten, en het is naar mijn mening de meest simpele en duidelijke manier om aan te geven dat er daar een rij bomen staat.
Je krijgt niet een kaart die vol staat met allemaal afzonderlijke bomen.
Bij Lange Voorhout ziet het er inderdaad wat druk uit, maar in het gebied waar veel houtwallen staan vind ik het dan wel weer goed passen.

Peter Elderson:

Zou het niet mogelijk zijn om een tree_row te renderen als een dunne of zelfs onzichtbare lijn waarbij elke node op de way een boomachtig rondje wordt (naar de smaak, ik bedoel stijl, van de renderer)? Dan kan je net zo precies of globaal mappen als je wil. De bomen staan dan op de aldaar heersende ondergrond. Kan je ook ronde en klaverbladvormige tree_rows mappen.

Dat zou een manier zijn om alle bomen te mappen zonder elk afzonderlijk te hoeven taggen.

Op zich is dit best een goed idee in stedelijke gebieden bijvoorbeeld. Maar voor een houtwal voldoet de huidige viltstiftstreep naar mijn mening prima.

'T is best een lastig geval trouwens, die tree_rows…
Maar ik ben wel van: houd het simpel. Hoe ingewikkelder dingen worden (als in: meerdere tags voor in wezen een tree_row) hoe lastiger het wordt om te bepalen wanneer en waar je die tags gebruikt. Dan denk ik dat je houtwallen beter kan taggen met tree_row en voor die boompjes die op een rij staan daarginds bij Lange Voorhout een nieuwe tag in het leven roept die puur gebruikt wordt voor het taggen van boomrijen in steden/bebouwd gebied.

Ik hoopte juist het zonder nieuwe tag af te kunnen, en dan zo dat het de renderaars meer mogelijkheden geeft voor realistische rendering.
Dat voorkomt dat mensen verkeerd gaan taggen omdat de korrekte tag verkeerd uitpakt op de kaart.
Want, tja, orchard rendert een gebied met veel bomenrijen nu beter dan tree_row… en orchards willen we toch zeker niet!

Peter_Elderson · 2018-04-05T20:11:45.000Z

Even ‘live’ gekeken naar die “houtwallen”. Sommige stukjes laten nog wel een paar afzonderlijke bomen zien, maar andere delen zijn eigenlijk aaneengesloten vrij lage begroeiing met vermoedelijk ook wat lage bomen ertussen, als afscheiding tussen de verkeersstromen en waterpartijen.
De huidige carto rendering van tree_row geeft dat wel aardig weer, maar dat is volgens mij niet de bedoeling van tree_row, als ik de wiki en de diskussies lees.

Zou je de groenwolkje-streepje rendering gebruiken dan is de oorspronkelijke bedoeling wél gediend, maar is @SubieLibero weer ongelukkig…
Met de wolkje-streepje rendering én een tag die de afstand tussen de bomen aangeeft, kan de renderaar allebei gelukkig maken. Ik heb even gezocht en de afstand tussen planten/struiken wordt algemeen met spacing aangeduid. Dat zou dan ook de key moeten zijn. Vergelijkbaar met andere renderbare maatvoeringskeys bv width.)

Voor de houtwal geef je bv spacing=1 aan (1 m tussenruimte) dan vormen de wolkjes een aaneengesloten lijn/rij en de streepjes een doorlopende middenstreep.

Voor een kilometer populieren langs een snelweg geef je spacing=30 of zo, een schatting is goed genoeg want wie kan het wat schelen hoe het precies staat? En wil je preciezer, dan meet je het gewoon na.

Een dubbele of zelfs driedubbele populierenrij zoals die hier in de buurt geregeld voorkomt (de “snelwegorchards” dus) kan je realistisch en niet overdadig weergeven met drie versprongen treerows met gelijke spacing, terwijl er nu een groot groen zebrapad zichtbaar is.

Voor het Lange Voorhout waar vele lange boomrijen in verschillende richtingen zijn maar meestal in het plaveisel of schelpengebied geplaatst, komen ze denk ik op spacing=10 te staan. Het nadeel daar is dat er ook losse bomen zijn, die zijn precies van hetzelfde soort alleen staan ze niet in de rij. Eigenlijk zou je daar de bommen in de tree_row nog iets meer willen laten lijken op de losse tree. Klus voor de ontwerpers? Maar dat is verfijning.

Dus ik heb eigenlijk drie aparte voorstellen, van minst ingrijpend tot meest ingrijpend:

Voorstel voor een betere (realistischer) rendering van tree_row zoals die bedoeld is;
Namelijk groenwolkje-streepje-…-groenwolkje met een standaard spacing
0 - 0 - 0 - 0
Voorstel voor toevoegen (en renderen) van de optionele key spacing=*
Standaardeenheid is m.
Minimumwaarde 1, je krijgt dan min of meer de groene streep die er nu ook is maar dan met een wat wolkigere tekening (de houtwal)

Hoe de spacing precies vertaalt naar de rendering op de diverse zoomniveaus (wolkjesafstand), zover ben ik nog niet om dat te kunnen verzinnen.
Een speciale value voor spacing die aangeeft dat elke nodes op de tree_row way de precieze plaats van een boom aangeeft.
Zo kun je treerows met ongelijke boomafstanden exact mappen zonder elke boom afzonderlijk te hoeven taggen.
Bijvoorbeeld spacing=“free”, of spacing=“nodes” of spacing=0

Voorstel 1 is puur voor de renderaars, om hun gebruikers beter te kunnen bedienen.

Libero · 2018-04-06T18:48:51.000Z

Begin je voorstel steeds beter te vinden Peter Elderson ;). Ben niet snel ongelukkig hoor, maak je geen zorgen :D.

PS: got it, met ‘free’ zet je op elke boom een node en dan komt daar een boom.

Peter_Elderson · 2018-04-06T19:12:18.000Z

SubieLibero:

Begin je voorstel steeds beter te vinden Peter Elderson ;). Ben niet snel ongelukkig hoor, maak je geen zorgen :D.

PS: got it, met ‘free’ zet je op elke boom een node en dan komt daar een boom.

Ik heb een beetje geoefend (zonder op te slaan). Je kan de nodes heel snel zetten als je ergens bekend ben of een mapillary eronder legt. Als de way ervoor zorgt dat de nodes als tree gerenderd worden, hoef je niet verder te taggen en is het klikklikklikklaar.

Maar alleen al een betere rendering zou al genoeg zijn om een heleboel straatbeeldbepalende bomen/boomrijen toe te kunnen voegen, en orchards te vervangen natuurlijk.

Ik heb in Den Haag en Nieuwerkerk aan den IJssel ff speciaal hiervoor rondgekeken, als je er eenmaal op let is het nu gewoon bedroevend hoe de kaart afwijkt van de werkelijkheid (want anders zou het er niet uitzien), en hoeveel alternatieve “oplossingen” er gebruikt zijn om het toch een beetje realistisch te krijgen.

Peter_Elderson · 2018-04-11T09:59:19.000Z

marczoutendijk:

Wil je het Lange Voorhout correct taggen, dan zou er op die schelpenvlakte (lokaal dus bekend als"Schelpenpad") minimaal:

highway=pedestrian

area=yes

surface=fine_gravel

moeten komen te staan.

Ik heb dit uitgevoerd, er zijn een aantal vlakken zo getagd. Nu zegt keepright dat een van die vlakken een floating island is. Keepright beschouwt de highway=pedestrian dus als een weg die altijd ergens mee verbinden moet zijn, ook al is het aangemerkt als een area.
De andere delen zitten toevallig allemaal ergens aan een landuse vast.

Wat te doen? Negeren? Of ergens op een intersectie gewoon maar een node neerpleuren zodat-ie verbonden is?

dvdhoven · 2018-04-11T10:50:26.000Z

Als je area een weg kruist, kun je daar een kruispunt maken. Sterker nog dat had je gelijk bij het intekenen van de area kunnen doen.
Ik weet niet of je de plugin utilsplugin2 al hebt geïnstalleerd, anders die asap installeren, die bevat zoveel handigheidjes, die verschijnen in de menubalk onder More tools.
Oa voor het maken van een kruising als twee wegen over elkaar liggen. Beide wegen selecteren en kiezen voor “add node at intersection”
Dat kan ook wat moeilijker, je maakt een node op de ene way en daarna selecteer je de andere way en bij tools kies je voor “Join node to way”
Als je area nergens een weg kruist, kun je gewoon verbindingsvoetpaadjes maken tussen de wegen en de area.

Peter_Elderson · 2018-04-11T11:19:41.000Z

Ok dus het is wel de bedoeling een om een intersectienode te maken ergens, begrijp ik.
Voor het routeren hoeft dat niet, want daarvoor loopt er ook al een lineaire weg door het midden. Maar om keep right te sussen zal ik het zo doen.

Andre_Engels · 2018-04-11T15:54:58.000Z

Peter Elderson:

Ok dus het is wel de bedoeling een om een intersectienode te maken ergens, begrijp ik.
Voor het routeren hoeft dat niet, want daarvoor loopt er ook al een lineaire weg door het midden. Maar om keep right te sussen zal ik het zo doen.

Overal waar 2 wegen elkaar kruisen, hoort een intersectienode, tenzij het fysiek onmogelijk is van de ene naar de andere weg te gaan. Dus in het bijzonder, ingeval je een area-weg hebt met een weg in het midden, dan aan beide kanten de weg in het midden met de area verbinden.

Peter_Elderson · 2018-04-11T17:32:51.000Z

Dank, dank! Ik leer het nog wel eens…

Peter_Elderson · 2018-04-16T10:28:19.000Z

Ik ben nog steeds aan het broeden. Ik wil een verbetering voorstellen maar ik moet dan wel met voorbeelden komen. Hoe maak je een rendering? Weten jullie daar tools voor?

Dit is nu mijn voorstel en daar wil ik wat voorbeelden bij verzamelen of maken:

0 - 0 - 0 - 0

**Improved rendering of tree_row
**The standard rendering should:

Indicate that its a row of separate objects, without indication of exactness of location.
Be more subtle, do not suggest a type of landcover but a row of objects placed on the land.
Show less green and more dark brown

Suggestion:

a discontinuous row of transparent or open logo style, crownlike green dots or clouds, very regularly spaced with brown hyphens (stem-colour) in between. No lining of the crowns and dots, edges are a bit ragged or cloudlike. Between the crowns and dots the surface colour should be visible.

No continuous line, because there is in fact no line.
The regularity of the lining shows that no exact locations are intended. Comparable to the regularity of tree-cover in a forest.
Crowns should be smaller compared to the current single tree rendering.
No stem points, because stem points would suggest stem locations.

o - o - o - 0

Elke hulp wordt zeer gewaardeerd! (Ik kan ook een prijsvraag uitschrijven?)

Kogacarlo · 2018-04-16T10:38:05.000Z

Een discussie over rendering is misplaatst hier.
Wij kunnen daar toch niks aan veranderen.
De jongens en meisjes van de rendering zitten, als ik het goed begrijp, hier en zien graag nieuwe programmeurs (coders)

Peter_Elderson · 2018-04-16T11:08:48.000Z

Kogacarlo:

Een discussie over rendering is misplaatst hier.
Wij kunnen daar toch niks aan veranderen.
De jongens en meisjes van de rendering zitten, als ik het goed begrijp, hier en zien graag nieuwe programmeurs (coders)

De diskussie wil ik daar gaan voeren maar dan wil ik er liefst goede voorbeelden bij. Daarvoor vraag ik ook hier hulp, want ik denk dat er best veel kennis over tools en voorbeelden aanwezig is. Ik heb zelf drie linkerhanden als het om plaatjes gaat.

marczoutendijk · 2018-04-16T15:26:09.000Z

Kogacarlo:

Een discussie over rendering is misplaatst hier.
Wij kunnen daar toch niks aan veranderen.
De jongens en meisjes van de rendering zitten, als ik het goed begrijp, hier en zien graag nieuwe programmeurs (coders)

Helemaal mee eens en als Peter die discussie goed leest kan hij ook zien dat ik me heb aangemeld als coder en dat ik er mee aan de slag ga.
Maar Peter moet vooral niet verwachten dat het morgen al af is

Peter_Elderson · 2018-04-16T20:34:35.000Z

marczoutendijk:

Kogacarlo:

Een discussie over rendering is misplaatst hier.
Wij kunnen daar toch niks aan veranderen.
De jongens en meisjes van de rendering zitten, als ik het goed begrijp, hier en zien graag nieuwe programmeurs (coders)

Helemaal mee eens en als Peter die discussie goed leest kan hij ook zien dat ik me heb aangemeld als coder en dat ik er mee aan de slag ga.
Maar Peter moet vooral niet verwachten dat het morgen al af is

Ik zie dat ik weer wat gemist heb, newb dat ik er sta! Ik ben hier blij mee, en ik verwacht geen wonderen vóór volgende week

Is het handig om de detaildiskussie over wat het probleem is, voorbeelden van situaties waar de vette groene streep tekortschiet, hoe het er precies uit zou moeten zien etc, daar in de github issue te voeren? Of is het handiger er een wiki-pagina over te maken met mijn voorstel/inzichten en dan kijken of we het kunnen modelleren tot een al dan niet 100% gedeeld eindvoorstel?

Gezien hoe de eerdere diskussies afliepen neig ik naar het laatste. Bruikbare inhoud uit de forums kan altijd op de wiki ingebouwd worden, en de forums kunnen naar de wiki verwijzen met af en toe een bump.

Peter_Elderson · 2018-04-20T10:33:51.000Z

Voor de tagging mailing list heb ik een apart tagging proposal gemaakt: https://wiki.openstreetmap.org/wiki/Proposed_features/spacing_-_draft

De verbeterde tree_row rendering staat hier eigenlijk los van, met dien verstande dat als de tagging goedgekeurd wordt, de rendering daarvan kan profiteren. Haalt het tagging-voorstel het niet, dan blijft het eerste deel van het renderingvoorstel gewoon staan: de dikke groene streep vervangen door een repetitief patroon, iets als 0-0-0-0- Afwisselend een groen kroon-achtig wolkje en een liggend bruin stamachtig streepje. Of zo.

Het tagging-voorstel is nog klad. Het is de eerste keer dat ik dit doe, ik zou het fijn vinden als ik kommentaar krijg over de vorm, voordat ik het aktief maak en de inhoudelijke schietpartijen beginnen. Waar ik echt heel slecht in ben is plaatjes, het zou mooi zijn als iemand daar iets zou kunnen bijdragen.

Peter_Elderson · 2018-04-24T18:23:22.000Z

Tagging proposal is nu niet meer klad-klad, maar “officieel” draft.

https://wiki.openstreetmap.org/wiki/Proposed_features/Key:spacing%3D*

Ik heb er diverse kommentaren al in verwerkt. De optie spacing=nodes heb ik eruit gehaald - spacing=N is opzettelijk niet exact gerelateerd aan de individuele objecten in de tree_row (of area, want het is ook op andere zaken van toepassing), maar een gemiddelde voor het gehele ding. Een optie gericht op exacte locatie is tegenstrijdig met deze bedoeling. Dus waar exacte positie van bomen belangrijk is moet je ze allemaal individueel plaatsen en taggen.