Renderen van tree_row

Peter Elderson · 2018-04-04 12:58:53

Anekdote (maar wel waar gebeurd!): in Nieuwerkerk is er een pad, genaamd Kleuterpad. Gevement, jaaaren geleden, is daar werk uitgevoerd, en de straatnaambordjes zijn weggehaald. Toen was het dus een naamloos pad. Op gemeentelijk materiaal werd het pad nog wel getekend maar zonder naam.

Maar op Google maps en andere online kaarten bleef de naam Kleuterpad stug gehandhaafd. Vorig jaar heb ik gewoon alsof mijn neus bloedde een Melding Openbare Ruimte gedaan: dat de straatnaambordjes ontbraken. En... nu heet het Kleuterpad weer officieel het Kleuterpad, inklusief mooie toekomstbestendige straatnaambordjes! Mijn Kleuterpad, ha!

mboeringa · 2018-04-04 13:39:19

Beste OSMers,

Ik ben diegene die verantwoordelijk is voor de laatste wijzigingen op het Lange Voorhout en Lange Vijverberg, en ook de tree_rows.

Ik heb deze wijzigingen gedaan omdat er veel niet meer klopte: de wegen op zowel de Lange Voorhout als Lange Vijverberg hebben grote wijzigingen ondergaan. De tram deelt nu voor een deel de rijbaan met het autoverkeer. Dit staat nu eindelijk correct in OSM (en dat is dan meteen de enige kaart! Google etc. geven het allemaal verkeerd weer en lopen flink achter: https://mc.bbbike.org/mc/?lon=4.313564& … p&marker=). Ook lag er nog een doodlopend trambaan stuk de Lange Voorhout op in OSM, dat er niet meer is, en zat er nog een rijbaan voor de (voormalige inmiddels?) Amerikaanse ambassade langs, die ook niet meer bestaat.

Kortom: tijd voor verbetering!

Daarbij heb ik ook het in mijn ogen incorrect landuse=forest hier verwijderd. Zoals Peter al aangeeft, lijkt het meer op een plein of park dan een gesloten bos met ondergroei als je daar ter plekke rondloopt. Tree_row leek mij toepasselijker, gezien de bomen toch echt netjes in gelid staan.

Ten aanzien van de rendering in Standaard: ja niet ideaal, maar dat zou toch niet leidend moeten zijn voor de tagging.

In mijn eigen ArcGIS Renderer pak ik het in ieder geval veel subtieler aan, en denk ik dat de rendering met op vaste afstand geplaatste boomkruin symbooltjes - en met tussenstreepje verbonden - goed werkt, zie plaatje.

Marco

Peter Elderson · 2018-04-04 13:39:32

marczoutendijk wrote:

Wil je het Lange Voorhout correct taggen, dan zou er op die schelpenvlakte (lokaal dus bekend als"Schelpenpad") minimaal:
1. highway=pedestrian
2. area=yes
3. surface=fine_gravel
moeten komen te staan. Dan doe je recht aan functie en formaat van dat middendeel dat je moeilijk een pad kunt noemen.
Dit beeld is duidelijk.
Bovendien is er volgens mij ook nog een speeltuintje ingericht en er staan een aantal kunstwerken.
En gebruik dan loc_name=Schelpenpad als je iedereen te vriend wilt houden.

Speeltuintjes en kunstwerken, dat zijn tijdelijke dingen. Ieder jaar na prinsjesdag wordt de Schelpenvlakte voor een paar maanden een kunstgalerij met meestal monstrueuze artefacten uit de ondergrondse depots van de Rijksdienst Beeldende Kunst.

Peter Elderson · 2018-04-04 14:13:22

mboeringa wrote:

Ik heb deze wijzigingen gedaan omdat er veel niet meer klopte: de wegen op zowel de Lange Voorhout als Lange Vijverberg hebben grote wijzigingen ondergaan. De tram deelt nu voor een deel de rijbaan met het autoverkeer. Dit staat nu eindelijk correct in OSM (en dat is dan meteen de enige kaart! Google etc. geven het allemaal verkeerd weer en lopen flink achter: https://mc.bbbike.org/mc/?lon=4.313564& … p&marker=). Ook lag er nog een doodlopend trambaan stuk de Lange Voorhout op in OSM, dat er niet meer is, en zat er nog een rijbaan voor de (voormalige inmiddels?) Amerikaanse ambassade langs, die ook niet meer bestaat.
Kortom: tijd voor verbetering!
Daarbij heb ik ook het in mijn ogen incorrect landuse=forest hier verwijderd. Zoals Peter al aangeeft, lijkt het meer op een plein of park dan een gesloten bos met ondergroei als je daar ter plekke rondloopt. Tree_row leek mij toepasselijker, gezien de bomen toch echt netjes in gelid staan.
Ten aanzien van de rendering in Standaard: ja niet ideaal, maar dat zou toch niet leidend moeten zijn voor de tagging.
In mijn eigen ArcGIS Renderer pak ik het in ieder geval veel subtieler aan, en denk ik dat de rendering met op vaste afstand geplaatste boomkruin symbooltjes - en met tussenstreepje verbonden - goed werkt, zie plaatje.

Je hebt volgens mij goed werk gedaan, ook de ondergrondse parking Museumkwartier staat er netjes op en de verwijderde tramrails, eindelijk! Dat de waterpomp tijdelijk (?) weg is voor reparatie kan jij ook niet helpen, en het nieuwe beeld van Thorbecke komt nog wel.

Lange Vijverberg staat MI goed als "park", dat stukje dient vooral voor vrije tijd en flaneren langs de Hofvijver. Lange Voorhout vind ik absoluut geen park, het is vooral werk- en verkeerszone. Door het als park aan te merken wordt het bij alle renderaars groen, al dan niet met boomwolkjes, en dat klopt echt niet met de situatieter plekke op de grond. Naar functie voldoet village_green goed, want in tegenstelling tot wat de naam suggereert is een village_green zelden groen! Hoe dat rendert weet ik niet.

Jouw rendering van tree_row is IMO precies goed, zo zou de standaardkaart het moeten doen. 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?

Last edited by Peter Elderson (2018-04-04 14:14:44)

Peter Elderson · 2018-04-04 14:53:02

marczoutendijk wrote:

Wil je het Lange Voorhout correct taggen, dan zou er op die schelpenvlakte (lokaal dus bekend als"Schelpenpad") minimaal:
1. highway=pedestrian
2. area=yes
3. surface=fine_gravel
moeten komen te staan. Dan doe je recht aan functie en formaat van dat middendeel dat je moeilijk een pad kunt noemen.
Dit beeld is duidelijk.
...
En gebruik dan loc_name=Schelpenpad als je iedereen te vriend wilt houden.

@Marco ben jij hiermee akkoord?

mboeringa · 2018-04-04 16:19:30

Peter Elderson wrote:

@Marco ben jij hiermee akkoord?

Dit moet je eigenlijk niet aan mij vragen, ik heb namelijk niets aan de naamgeving veranderd, slechts wegen verlegt.

Wat "Schelpenpad" betreft, weet ik niet of er nog enige vorm van historische betekenis aan zit. Vroeger, in de Middeleeuwen, liepen er natuurlijk ook al paadjes vanuit het Haagse historische centrum naar het strand en Scheveningen. Het duin begon zowat naast het binnenhof (nu ja, ook weer niet helemaal, maar ver was het niet).

Los daarvan echter, als de Hagenezen het "Schelpenpad" met hoofdletter S noemen, dan denk ik dat dat genoeg reden zou zijn om het zo te noemen.

De tagging als pedestrian area lijkt mij sowieso goed.

multimodaal · 2018-04-04 16:38:28

mboeringa wrote:

Daarbij heb ik ook het in mijn ogen incorrect landuse=forest hier verwijderd. Zoals Peter al aangeeft, lijkt het meer op een plein of park dan een gesloten bos met ondergroei als je daar ter plekke rondloopt. Tree_row leek mij toepasselijker, gezien de bomen toch echt netjes in gelid staan.

Hoi Marco,
Dit lijkt me inderdaad een goed tagging als je niet elke boom apart wil taggen, het is duidelijk een bomenrij /-laan.

Het alternatief van bomen -buiten het bos- als landuse=forest taggen is doorgaans inderdaad veel minder aantrekkelijk: het is geen bosbouw (use) en wat betreft landcover: onder het bladerdek dat wij op de luchtfoto zien zit doorgaans geen bosgrond, maar een plein, veld..

Ook kan je met het taggen van enkele (of kleine aantallen) grote bomen ook in een rare ondehoudscycles komen met verschillende luchtfoto's: per foto is de omtrek weer anders, naar gelang leeftijd en seizoen.

Vanwege die verschilende lagen is toch een node voor een enkele boom wellicht beter dan een area.

Maar vooral: erg mooie rendering die je maakt!
(zowel voor tree_row als in het algemeen)

Is die ook voor het brede publiek te zien?
Of alleen via een Arcgis-account ?

marczoutendijk · 2018-04-04 17:57:12

Peter Elderson wrote:

Naar functie voldoet village_green goed, want in tegenstelling tot wat de naam suggereert is een village_green zelden groen! Hoe dat rendert weet ik niet.

Gewoon een groen vlak, net als gras maar iets andere tint.

Peter Elderson wrote:

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?

Wat mij betreft is dit weer volkomen overbodig en valt in dezelfde categorie als de mapper die wilde gaan taggen dat ze bij kruidvat geen eurocenten accepteren.

marczoutendijk · 2018-04-04 18:41:45

En voor iedereen die gaat sleutelen aan het Lange Voorhout: let op dat je de routerelaties die er nu lopen, niet verbreekt!
Laat gewoon de highway=footway die er nu al is gewoon intakt en teken daaromheen de highway=pedestrian.

Peter Elderson · 2018-04-04 19:22:41

marczoutendijk wrote:

Peter Elderson wrote:
Naar functie voldoet village_green goed, want in tegenstelling tot wat de naam suggereert is een village_green zelden groen! Hoe dat rendert weet ik niet.
Gewoon een groen vlak, net als gras maar iets andere tint.
Peter Elderson wrote:
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?
Wat mij betreft is dit weer volkomen overbodig en valt in dezelfde categorie als de mapper die wilde gaan taggen dat ze bij kruidvat geen eurocenten accepteren.

Een andere rendering in plaats van die botte groene strepen is van een andere orde dan een bijkomend funktioneel weetje over een winkel. En het verandert niks aan de tagging. Het is ook bij de renderers een punt, ook indikatie van afstand/verdeling in relatie tot de hoeveelheid werk die het kost hem het met individuele trees goed aan te geven.
Hoe groot de kroon van elke boom is gaat me dan weer een stap te ver.

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, dat maakt de kaart veel mooier en accurater. En backwards compatible he. Kom daar nog maar eens om, op heden.

SubieLibero · 2018-04-05 09:12:45

Peter Elderson wrote:

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

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.

Last edited by SubieLibero (2018-04-05 09:19:33)

marczoutendijk · 2018-04-05 09:57:46

/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-05 10:09:42

Peter Elderson wrote:

[..]
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.

Last edited by marczoutendijk (2018-04-05 10:49:32)

Peter Elderson · 2018-04-05 12:05:12

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.

Last edited by Peter Elderson (2018-04-05 12:09:46)

Peter Elderson · 2018-04-05 14:53:26

SubieLibero wrote:

Peter Elderson wrote:
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 wrote:

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-05 21:11:45

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:

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

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

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

SubieLibero · 2018-04-06 19:48:51

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

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

Peter Elderson · 2018-04-06 20:12:18

SubieLibero wrote:

Begin je voorstel steeds beter te vinden Peter Elderson . Ben niet snel ongelukkig hoor, maak je geen zorgen .
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-11 10:59:19

marczoutendijk wrote:

Wil je het Lange Voorhout correct taggen, dan zou er op die schelpenvlakte (lokaal dus bekend als"Schelpenpad") minimaal:
1. highway=pedestrian
2. area=yes
3. 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-11 11:50:26

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-11 12:19:41

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-11 16:54:58

Peter Elderson wrote:

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-11 18:32:51

Dank, dank! Ik leer het nog wel eens...

Peter Elderson · 2018-04-16 11:28:19

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:

1. Indicate that its a row of separate objects, without indication of exactness of location.
2. Be more subtle, do not suggest a type of landcover but a row of objects placed on the land.
3. 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-16 11:38:05

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)

Last edited by Kogacarlo (2018-04-16 11:41:23)

Announcement

#26 2018-04-04 12:58:53

Re: Renderen van tree_row

#27 2018-04-04 13:39:19

Re: Renderen van tree_row

#28 2018-04-04 13:39:32

Re: Renderen van tree_row

#29 2018-04-04 14:13:22

Re: Renderen van tree_row

#30 2018-04-04 14:53:02

Re: Renderen van tree_row

#31 2018-04-04 16:19:30

Re: Renderen van tree_row

#32 2018-04-04 16:38:28

Re: Renderen van tree_row

#33 2018-04-04 17:57:12

Re: Renderen van tree_row

#34 2018-04-04 18:41:45

Re: Renderen van tree_row

#35 2018-04-04 19:22:41

Re: Renderen van tree_row

#36 2018-04-05 09:12:45

Re: Renderen van tree_row

#37 2018-04-05 09:57:46

Re: Renderen van tree_row

#38 2018-04-05 10:09:42

Re: Renderen van tree_row

#39 2018-04-05 12:05:12

Re: Renderen van tree_row

#40 2018-04-05 14:53:26

Re: Renderen van tree_row

#41 2018-04-05 21:11:45

Re: Renderen van tree_row

#42 2018-04-06 19:48:51

Re: Renderen van tree_row

#43 2018-04-06 20:12:18

Re: Renderen van tree_row

#44 2018-04-11 10:59:19

Re: Renderen van tree_row

#45 2018-04-11 11:50:26

Re: Renderen van tree_row

#46 2018-04-11 12:19:41

Re: Renderen van tree_row

#47 2018-04-11 16:54:58

Re: Renderen van tree_row

#48 2018-04-11 18:32:51

Re: Renderen van tree_row

#49 2018-04-16 11:28:19

Re: Renderen van tree_row

#50 2018-04-16 11:38:05

Re: Renderen van tree_row

Board footer