Re: [OSM-talk-be] 'losse' wegen

[Tim Couwelier]

Het is een gevalletje van 'taggen voor de render'.
De mapper in kwestie is aan het micro-mappen geweest (maar is er gelukkig
wel consistent in geweest), en heeft ze als highway = footway getagd,
terwijl dat helemaal niet nodig was.

Ik gok overigens dat (doordat de kleur vrij dicht aanleunt bij die van een
residential landuse) het effect visueel knal hetzelfde was geweest zonder
ze toe te voegen.

Corrigeren zou kunnen door ze in bulk te selecteren in JOSM en dan zo in 1x
de tag van alle geselecteerde objecten aan te passen, alleen weet ik
eerlijkheidshalve ook niet zo zeer naar wat je ze zou aanpassen dan.
'Private verharding' zonder te specifiëren wat, daar ken ik niet meteen een
gepaste tag voor.

Op ma 21 dec. 2020 om 08:31 schreef joost schouppe :

> Dag Meannder,
>
> De oorzaak lijkt me dat iemand al de opritten heeft ingetekend als vlak,
> maar zonder ze te verbinden met de rest van de weginfrastructuur. Dat ziet
> er wel mooi uit, maar het is volstrekt zinloos voor navigatie. En als je
> dus een woning hebt die nabij verschillende wegen ligt, dan gaat de oprit
> niet helpen om dichter bij je bestemming gestuurd te worden. Alleszins is
> de foutmelding wel terecht: er zijn hier talloze verkeerseilandjes
> gecreëerd.
>
> Mvg,
> Joost
>
> Op zo 20 dec. 2020 18:44 schreef meannder :
>
>> Dag-ga-dag,
>>
>> In Zwevezele zijn, al een aantal maanden, ontelbaar veel
>> 'niet-verbonden' wegen te zien op
>>
>> https://www.keepright.at/report_map.php?zoom=16=51.0357=3.2121
>>
>> Zijn dit schoonheidsfoutjes -toch niet te zien op de map-, de moeite om
>> op te lossen  en desgevallend... HOE (zonder uren werk)?
>>
>> groet, meannder
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] De kaainummers van de haven van Gent.

[Tim Couwelier]

Phillipe,

Ze zijn beschikbaar als open data:
https://data.stad.gent/explore/dataset/kaainummers-north-sea-port/export/?flg=nl
Je kan nog kiezen in welk formaat.



Op wo 21 okt. 2020 om 09:59 schreef Philippe Casteleyn <
philippecastel...@hotmail.com>:

> Dit is al mijn derde poging na Facebook en het OSM forum.
>
> Waar vind ik de kaainummers van de Gentse haven ?
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] waymarked or not?

[Tim Couwelier]

ey should definitely be put in their own data model." They're
>>> still local/regional/... hiking/cycle/... routes. Adding some tag like
>>> 'virtual=yes" on the route relations and nodes should suffice. (It will be
>>> a bit more complicated because a node can be both a virtual hiking node and
>>> a real cycle node.)
>>>
>>> Regards,
>>>
>>> StijnRR
>>>
>>> On Monday, October 19, 2020, 07:34:48 PM GMT+2, Steven Clays <
>>> steven.cl...@gmail.com> wrote:
>>>
>>>
>>> Tendency in Toerisme Vlaanderen > ALL hiking nodes will go virtual
>>> within 10 years or so. (At least, that is their vision) So if you do not
>>> follow this tendency, you make OSM irrelevant for routes. I'd make a
>>> thorough choice in the official operators AND their choices. Eg. Natuurpunt
>>> DOES stick to signposting AFAIK.
>>>
>>> Op ma 19 okt. 2020 om 14:47 schreef Matthieu Gaillet <
>>> matth...@gaillet.be>:
>>>
>>>
>>> Wether they are following another route is not relevant since it’s a
>>> separate relation.
>>>
>>> Matthieu Gaillet
>>>
>>> On 19 Oct 2020, at 14:33, Wouter Hamelinck 
>>> wrote:
>>>
>>> Are there any EV routes in Belgium that are not also LF or RV?
>>>
>>> Wouter
>>>
>>> On Mon, 19 Oct 2020, 12:29 Matthieu Gaillet, 
>>> wrote:
>>>
>>> Things are actually much less obvious and deserve a real second thought
>>> before taking position : it just came up to my mind that much of the
>>> Eurovelo network is still currently completely virtual (work in progress),
>>> yet deleting in from our map would be totally irrelevant since this routes
>>> are actually existing by the simple fact that thousands of users are using
>>> it.
>>>
>>> Matthieu Gaillet
>>>
>>> On 13 Oct 2020, at 19:21, joost schouppe 
>>> wrote:
>>>
>>> I think we shouldn't actively map purely virtual routes. But there's a
>>> lot of info that only lives on paper and still is relevant to OSM. So I
>>> find it hard to give it a hard no. What is essential though, is that we
>>> don't make a mess of the tagging. A route, right now, is something you can
>>> expect to see waymarked. If someone starts mapping virtual routes, they
>>> should definitely be put in their own data model.
>>>
>>> Op di 13 okt. 2020 om 13:27 schreef Matthieu Gaillet <
>>> matth...@gaillet.be>:
>>>
>>>
>>> That might be true but apply as well to signposted trails on the fled…
>>> I’m not fully convinced.
>>>
>>> But it is true that other websites or apps are specialised into
>>> publishing “virtual" trails and that might be something pertaining to the
>>> OSM project.
>>>
>>> Matthieu Gaillet
>>>
>>> On 13 Oct 2020, at 13:20, Wouter Hamelinck 
>>> wrote:
>>>
>>> Hi all,
>>>
>>> I follow those who propose to limit ourselves for the mapping purposes
>>> to what is waymarked on the ground.
>>> Taking routes from other sources (be they official or not) makes
>>> everything so fluid that we will end up with a huge mixed bag of gpx files
>>> that were at some point in time on some website of an authority, routes
>>> that are actively promoted, routes that were actively promoted for some
>>> event a few years ago and still can be found somewhere but are no longer
>>> maintained, routes where nobody really knows where they come from but they
>>> sound kind of official...
>>> It will get messy...
>>>
>>> Wouter
>>>
>>> On Tue, 13 Oct 2020, 09:51 Francois Gerin, 
>>> wrote:
>>>
>>> +1 for the "end user's perspective".
>>>
>>> From my point of view, two key rules make the ground for OSM as pointed
>>> out in several places of the documentation:
>>>
>>> 1. Think to end users
>>>
>>> 2. Map what really exists
>>>
>>> "Map what really exists" is visible in many places in the docs, and this
>>> is indeed important, up to some "threshold".
>>> "Think to the end users" is much less visible, but is visible anyway.
>>>
>>> I'm afraid that, being driven mostly by technical profiles/mappers, the
>>> "Map what exists" rule seems to take the precedence because it is more
>>> visible.
&g

Re: [OSM-talk-be] waymarked or not?

[Tim Couwelier]

I'm inclined to go by 'mapping verifiable ground truth'. Which means no -
don't add them unless signposted along the way.

Op di 13 okt. 2020 om 08:45 schreef s8evq :

> I do not think they should be in OSM, and I wouldn't mind deleting them. :)
>
> First of all, they are harder to keep up to date and verify.
> Secondly, like you said, where do you draw the line. Who's routes do we
> add and who's not?
>
> For example, Natuurpunt and some of the local tourism offices already have
> 'virtual' hikes, where they only suggest which node numbers to combine. On
> the ground, nothing is marked. I don't think this should be in OSM.
>
> If I get this correctly, 'Randonnées en Boucle' (SGR) are hikes made out
> of parts of existing GR trails? I wouldn't add that. The possibilities are
> just endless...
>
> On Mon, 12 Oct 2020 19:57:59 + (UTC), Stijn Rombauts via Talk-be <
> talk-be@openstreetmap.org> wrote:
>
> > Hi,
> >
> > There is a guideline or rule that only waymarked hiking/cycle/... routes
> should be added to OSM. Not everyone agrees and there are some
> non-waymarked routes in OSM because nobody, not even me, dares to remove
> them.
> > Anyway, that rule/guideline is getting in trouble because some official
> routes are not waymarked anymore.
> > Provincie Vlaams-Brabant enlarged the 'wandelnetwerk Getevallei', but
> the new nodes and routes are not waymarked anymore (too expensive). But
> there is a map, a website and an app. [1]
> > The municipality of Profondeville has the project '1000 bornes' (40
> parcours pour vélos de route et VTT): only gps-tracks on route-you. [2]
> > More will probably follow (or perhaps already exist).
> >
> > So, what do we do? Or where do we draw the line? Because the line
> between what can be considered as official routes or not, could (in the
> future) become very thin. Or what do we do with the 'Randonnées en Boucle'
> (SGR)? What if Natuurpunt/Natagora starts with 'virtual' walking routes?
> >
> > What is your opinion?
> >
> > Regards,
> >
> > StijnRR
> >
> > P.S. The new map of 'wandelnetwerk De Merode' has OSM as background
> layer. Thanks to everyone who contributed.
> >
> > [1] https://www.toerismevlaamsbrabant.be/pagina/werken-wandelnetwerken/
> > [2] https://www.profondeville.be/loisirs/sport/1000bornes
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Fietsstraatzones in Leuven and a question about zones inside zones

[Tim Couwelier]

F4a should remain yes, despite both implying the same speed limit, UNLESS
the local gov removed the F4a signs due to the 'fietszone' completely
overlapping with the 'zone 30'.
Ideally, for the 'zone 30', differentiate between 'normal' with F4a only
and 'school- zone 30'  (F4a + A23)

If there's living streets within, I'd say the restrictions 'stack': no
overtaking, 20 km/h.
There may actually be a slight nuance here - generally in case of possible
contradiction, the rule applies 'traffic sign takes priority over traffic
rules'. The speed limits in both fietszone and living_street are traffic
rules, but this might leave a loophole where 'zone 30' as a sign takes
priority.

There used to be a loophole where a C43 70km/h would trump the 50km/h speed
limit in a built up area until the first intersection (extent of the
validity for the C43) but afaik that's been 'patched' in legislation now.
This might just be an unforeseen edge case opening another such loophole,
although I'm not 100% sure on this.


Sidenote: I think I agree with not making a seperate sign for this, but
just giving it a 'zonal' extent. If anything, F4a/b signs existing as such
is confusing. But then again, so were the original streetsigns as they were
semi-assumed to be zonal, but the law wasn't overly specific (and didn't
mention it being zonal). Readability, in database or map format, is far
better if you speak of 'zonal C43' and 'zonal F111' without having to know
another number for the same type of thing.

Op zo 30 aug. 2020 om 14:50 schreef Jo :

> Hi,
>
> I added the new fietsstraatzones in Leuven to the map. They will be in
> vigor on September 1st. The legislator didn't create a separate sign, they
> just decided that it's allowed use F111 on a ZONE sign...
>
> I do like to distinguish between the 'real' cycle streets and the
> 'pretenders', so the ones inside zones and the ones connecting the zones, I
> guess. I used BE:F111zone as the traffic_sign. I may have done something
> silly though, as I removed the F4a from the traffic sign tag.
>
> If you search for F111 you get all.
> If you search for F111zone you get all the ones inside the zones.
> If you search for "F111 -F111zone" in JOSM, you get only the cyclestreets
> with an actual cycle street sign.
>
> If you search for F4a you get all the streets inside the zone30, but the
> cycle streets are not included in that. How do we want to work with zones
> within zones? There are also parking zones...
>
> Should I have put traffic_sign=BE:F111;BE:F4a;BE:F1a ?
>
> Initially I didn't because both are limited to 30km/h, but now I'm
> thinking I should have.
>
> What about the living_street ways? They are also inside the zone30 (and in
> built-up area), but the traffic rules that apply are BE:F12a. Do we add
> BE:F12a;BE:F4a;BE:F1a ?
>
> Jo
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Weggetje verdwenen, hoe terug ?

[Tim Couwelier]

Bijlage bleeft hangen wegens groter dan 80kb, maar hierbij even ter
illustratie hoe je ze kan traceren met de 'skyview' laag.  Is een soort
hoogtemodelweergave op grondniveau, de bomen zie je dus niet.. en het pad
wordt zichtbaar.

https://framapic.org/r01ExtbzPorU/Z1Zri8oU24QM.jpg

(ik had al even afzonderlijk gemaild naar de betrokken persoon, maar
mogelijks zijn er nog mensen waarvoor dit een meerwaarde kan betekenen.)


Op di 12 mei 2020 om 10:57 schreef Wannes Soenen :

> Ok, dan lijkt me het het “handigste” dat ik een GPX neem en het pad terug
> teken (want het zit onder de bomen)
> Die relaties, en GR enz toevoegen/verleggen, zal ik eerst eens moeten
> bestuderen, want dat heb ik nog nooit gedaan.
>
> Op 12 mei 2020, om 10:53 heeft Sander Deryckere  het
> volgende geschreven:
>
> Hallo,
>
> Het hangt er van af hoe lang de wijziging geleden is.
> Als het vrij recent is (enkele dagen), kan je de geschiedenis van een
> gebied opvragen (de geschiedenis knop op de hoofdpagina).
> Maar deze wijziging lijkt langer geleden te zijn, dus valt dit moeilijk te
> bespeuren.
>
> Wat je wel kan is bekijken welke objecten waarschijnlijk ook gewijzigd
> zijn bij die aanpassing (zoals het fietspad dat nu gebruikt wordt).
>
> 
>
> Als je dat fietspad selecteert, en de geschiedenis opvraagt, dan kom je
> hier terecht: https://www.openstreetmap.org/way/24520913/history
>
> Er is dus in de laatste maanden tamelijk wat aangepast aan het pad.  In
> het bijzonder zie ik een wijziging van 4 maand geleden met het commentaar 
> "cycleroute
> 03-04 update: broken (again), now due to missing segments". Wat er op
> wijst dat iemand er voor die regio heeft aangepast, zonder rekening te
> houden met de relaties.
>
> Het is dus waarschijnlijk niet 1 iemand die de relatie verlegd heeft, maar
> iemand heeft dat pad verwijderd, en iemand anders heeft de relatie opnieuw
> verbonden met de bestaande paden...
>
> Mvg,
> Sander
>
> Op di 12 mei 2020 om 10:18 schreef Wannes Soenen :
>
>> Hoi,
>>
>> Ik zie dat er zeer lokaal, een wegje verdwenen is op de kaart.
>> Ik kan dat er zelf terug op gaan zetten, maar dan is de kans groot dat
>> diegene die de edit gedaan heeft het weer wist.
>>
>> Hoe kan ik 1) zien wie de edit deed, of er een comment bij was? 2)
>> rollback doen
>>
>> Het betreft een pad net ten zuiden van het Ringfietspad op
>> https://www.openstreetmap.org/edit#map=18/51.20462/4.44275
>> De plaatselijke merkkringen van het GR-pad (en van op de GR site) loopt
>> wel degelijk over dat pad, niet over het fietspad.
>> Dus, de huidige gemaakte situatie is fout, want 1) pad is niet meer
>> gemapt 2) GR loopt over het fietspad.
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] tile.osm.be

[Tim Couwelier]

As I understood from Jonathan, the process isn't fully automated yet. Was
supposedly to get updated on a near-weekly basis, but it must've slipped
from attention.
I'd guess that moving on towards a full automation of the process would go
a long way?

Op di 10 mrt. 2020 om 11:05 schreef rodeo .be :

> Hey all,
>
> I see this tile server has not been updated the last months. Is the future
> of that tile service unsure?
>
> Btw, we asked several organiations to use those tiles in the past (see
> here ):
> "*Met OpenStreetMap Belgium hebben we in samenwerking met een sponsor een
> tile-server optgezet die wel expliciet bedoeld is om te gebruiken in uw
> situatie.*"
>
> I think it would be worth it to keep that service! How can we help?
>
> KR
> Maarten
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Overdreven gedetailleerde mapping ?

[Tim Couwelier]

Toch ook even mijn 'two cents' ertussen gooien.

Ik begrijp de sceptische insteek: moet je zo'n details gaan mappen, terwijl
er nog zoveel meer is wat ontbreekt?.
In geval van een BETAALDE dienstverlening, ben ik het er 100% mee eens dat
het een rommeltje is als je zo te werk gaat, 'resultaatgericht' is dat niet.

Maar dat is het hier niet. Het is een database (en dus meer dan gewoon een
kaart), wat een rommelig datamodel heeft maar waar zeer veel in terecht kan.
En als iemand dat leuk vindt om daar bomen in te mikken, of brievenbussen,
of verlichtingspalen .. dat ie lekker doet. Tuurlijk is dat een beetje
micromappen. Maar ik heb nu eenmaal meer met het groen op mijn wijk, dan
met de verlichtingspalen in Antwerpen.

Wel pleit ik er voor een zeker 'gebiedje' dan wel op een gelijke maatstaf
te behandelen. Als je het doet, zorg dan dat je consequent bent, voor de
wijk of als het even kan je kleine gemeente.



Op ma 4 nov. 2019 om 10:33 schreef Marc Gemis :

> Chris,
>
> je hoeft niet bang te zijn om je mening te geven. Alvast bedankt
> ervoor, goed dat je die quote ivm innovatie aanhaalt.
>
> Je kan de capaciteit van een parking ook taggen via de "capacity" tag
> op amenity=parking. Dat zou een een plaatsbesparende (?) mogelijkheid
> zijn.
> Maar was er onlangs niet ergens de vraag hoeveel vierkante meter er
> aan parking gespendeerd wordt ? Daarvoor heb je meer aan parking
> spaces (als je onderscheid wil maken tussen staanplaatsen en wegen
> ertussen).
>
> Voor bloembakken e.d. denk ik ook weer aan navigatie voor
> slechtzienden, of zelfs rolsstoelgebruikers (tenminste als we de
> voetpaden ook als vlakken zouden tekenen), zodat men nog weet hoeveel
> (of hoe weinig) plaats er is tussen muur en bloembak.
> Ook voor het bepalen van oversteekplaatsen voor voetgangers in het
> algemeen geeft het mappen van grasperken e.d. aan waar er hindernissen
> zijn.
>
> maar we staren ons inderdaad soms blind op data voor de navigatie van
> auto's en in iets mindere mate van fietser en voetgangers zonder enige
> vorm van beperking.
>
> mvg
>
> m.
>
> On Mon, Nov 4, 2019 at 9:44 AM Chris Van Bael 
> wrote:
> >
> > Hallo,
> >
> > long-time lezer hier, af en toe wat bijgedragen, maar vooral OSM
> gebruikt. Dus als jullie mijn commentaar niet belangrijk vinden, ook goed.
> >
> > Om even in te haken op wat wel of niet mappen. Op de OSM wiki staat: "
> The project aims to promote new and interesting uses of this data"
> > Als je geen parkeerplaatsen of zelfs bloemperkjes mapt, dan ga je in
> ieder geval daar nooit een nieuw of interessant gebruik voor krijgen.
> > Zeker voor parkeerplaatsen zie ik al verschillende mogelijkheden:
> > - voor winkels, overheid en andere organisaties nagaan hoeveel
> parkeerplaatsen er zijn in een regio om aan de hand daarvan bepaalde
> beslissingen te nemen.
> > - voor (semi) autonome auto's om te weten of men hier kan parkeren of
> wat de kans is dat er een vrije parkeerplaats is
> > Zelf kan ik niets bedenken voor bloemperkjes, maar misschien een
> milieudeskundige wel? (afstand tussen bloemperken om levensvatbaarheid van
> bijen te onderzoeken?)
> > Ik zou dus zeker niet zeggen om iets niet te mappen omdat we er nu geen
> applicatie voor kunnen bedenken.
> >
> > Waarom zou je iets niet willen mappen?
> > - onderhoud: dit vind ik nog de belangrijkste reden om iets niet te
> mappen: mogelijk heb je liever een kleinere, maar correcte database, dan
> een uitgebreide, maar onbetrouwbare database. Hierover vind ik echter niets
> terug op OSM.
> > - opslag: meer data neemt natuurlijk meer ruimte in, maar we spreken
> hier niet over foto's of films.
> > - performantie: meer nodes kunnen queries vertragen. Maar voor we data
> input gaan beperken, zou er dan eerst naar de queries gekeken moeten worden
> of die juist gemaakt zijn.  Zelfs als die dat zijn, kan je het misschien
> oplossen door er meer hardware tegenaan te gooien. Kost geld? Wel, dan moet
> OSM misschien meer geld zien op te halen ipv de data te beperken.  Ik lees
> nergens op OSM dat men enkel een routeplanner wil zijn.
> >
> > Ivm junk: ik denk dat dat minder speelt dan bij Wikipedia omdat het toch
> wat moeilijker is om een aanpassing te maken en deze ook minder zichtbaar
> is.
> > Maar: het is niet omdat er geen goede procedure is om met junk om te
> gaan, dat men dan maar minder moet gaan mappen.
> >
> > Bedankt om dit te lezen,
> >
> > Chris
> >
> >
> >
> > On Sun, 3 Nov 2019 at 20:04, Karel Adams  wrote:
> >>
> >> Marc,
> >>
> >> (parenthese over mijn conflict met DWG: ik besef dat ik niet altijd even
> >> correct heb gehandeld. En ik had er ook niet zo uitvoerig over moeten
> >> vertellen, alhier, inderdaad. Blijft de frustratie dat er op een
> >> verzoenend bericht mijnerzijds niet werd ingegaan, er kwam zelfs geen
> >> "neen", er kwam gewoon niks... Blijft mijn waarschuwing: "let wat gij
> >> doet, de DWG kan hard en niet altijd even konsekwent ingrijpen."
> >> Communicatie vooraf is erg belangrijk voor die lieden, en daar kan
> 

Re: [OSM-talk-be] fietsstraten in Mechelen

[Tim Couwelier]

Een 'fietszone' is niet meer dan een fietsstraat een 'zonale geldigheid'
gegeven.
In geval van overlap lijkt me de meest strikte bepaling gelding.

Inhaalverbod op fietsers dus, maar met de maximumsnelheid op 20 km/u.
cyclestreet = yes en highway = living_street ?


Er zullen m.i. nog een aantal gemeentes tegen de lamp lopen, met betrekking
tot de regel dat er op elk punt *maximaal 3 geldende zonale beperkingen*
mogen optreden.
Daarbij denk ik aan:
- Zones 30
- Zones parkeerverbod
- Zones tonnagebeperking
- Fietszones
- ...

Zeker in centra is combinatie 'zone 30' / tonnagebeperking /
parkeerreglementering / fietszone niet ondenkbaar.

Het issue is blijkbaar ook al voorgelegd:
http://docs.vlaamsparlement.be/pfile?id=1486490



Op di 29 okt. 2019 om 10:01 schreef Santens Seppe :

> Weet iemand wat dit betekent voor bestaande woonerven?
>
>
>
> *Van:* joost schouppe [mailto:joost.schou...@gmail.com]
> *Verzonden:* maandag 28 oktober 2019 17:55
> *Aan:* OpenStreetMap Belgium
> *Onderwerp:* [OSM-talk-be] fietsstraten in Mechelen
>
>
>
> Hoi,
>
>
>
> Mappers in Mechelen, een klein projectje: de stad heeft het gehele centrum
> aangeduid als "fietsstraten". Zie: https://www.mechelen.be/fietszone
>
>
>
> De tagging wordt hier uitgelegd:
> https://wiki.openstreetmap.org/wiki/Key:cyclestreet#Belgium
>
>
>
> Aangezien echt het hele gebied dus maximumsnelheid 30 en cyclestreet=yes
> krijgt, is het een relatief eenvoudige edit. Anderzijds is het wel
> gemakkelijk om hierbij fouten te maken (bijvoorbeeld per ongeluk ook de
> huizen aan te duiden als cyclestreet ofzo, ik vind het niet uit). Dus vraag
> gerust live hulp via Riot: https://riot.im/app/#/room/#osmbe:matrix.org
>
>
> --
>
> Joost Schouppe
>
> OpenStreetMap  |
> Twitter  | LinkedIn
>  | Meetup
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] nieuwe-fiets-en-voetgangerstunnel-in-ekeren

[Tim Couwelier]

Karel,

het is HIER te doen:
https://www.openstreetmap.org/way/31647365#map=16/51.2843/4.4347=N

https://assets.antwerpen.be/srv/assets/api/download/28cef7be-5225-474e-93ff-8d67322be61f/plan_tunnel.pdf
is wat er zou moeten uitgevoerd zijn.

En voor wie houdt van wat info over hoe ze zo'n tunnel daar onder schuiven:
https://www.antwerpen.be/nl/info/5610f78bcaa8a762cd8b4567/bouw-van-een-fietstunnel

Op wo 19 jun. 2019 om 20:12 schreef Karel Adams :

> cfr.
>
> https://www.vrt.be/vrtnws/nl/2019/06/19/nieuwe-fiets-en-voetgangerstunnel-in-ekeren-geopend/
>
> Ofwel kijk ik op de verkeerde plaats, ofwel is deze tunnel nog helemaal
> niet ingetekend in OSM? Wie wie wie?
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] bridge or tunnel?

[Tim Couwelier]

I'll agree with everyone else on the given selection here.

As for how I try to decide:
Ideally, you'd have the history of 'what came first'. Whichever level this
one is at goes as the 'baselevel'.
Either a new road / railway / .. goes:
OVER it, making that a bridge
UNDER it, making it a tunnel
AT THE ORIGINAL LEVEL, making the existing road/path a bridge or tunnel
based on how that got adjusted.

That makes this a railway-bridge:
https://www.google.be/maps/@50.9501557,3.1304248,3a,60y,255.18h,91.97t/data=!3m6!1e1!3m4!1sV8dGdG1hKMYxX3JldKdTSA!2e0!7i13312!8i6656
But this, just a bit further, and at the same level as the road shown in
the previous example, a tunnel for cyclists:
https://www.google.be/maps/@50.9516067,3.1299799,3a,48.9y,281.94h,86.62t/data=!3m6!1e1!3m4!1sPooi08Nvz-feFB6XzaibnQ!2e0!7i13312!8i6656

Hope that makes sense, I personally feel it matches with how people tend to
label things.





Op di 28 mei 2019 om 00:04 schreef Pieter Vander Vennet <
pieterv...@gmail.com>:

> Cool collection of bridges (except #2). I too think that if its not dug,
> it's not a tunnel.
>
> I have another cool example, not from belgium though:
> https://www.google.be/maps/@45.5067122,6.6792676,3a,75y,267.08h,77.06t/data=!3m6!1e1!3m4!1stJwtCeCLHlLxMPnVB_ZYdw!2e0!7i13312!8i6656?hl=nl
>
> This view is on a bridge (over a small valley) which acts as ski piste (in
> winter), and continues through a building (which has a ski piste on top).
>
> Met vriendelijke groeten,
> Pieter Vander Vennet
>
>
> Op ma 27 mei 2019 om 22:44 schreef GeDeOn . :
>
>> Hi Stijn and all
>>
>> In my opinion, a tunnel is something that was dug, in a hill or in
>> mountain, under a river, ...
>>
>> Otherwise I would think of a viaduct.
>>
>> In that regard only your case #2 is a tunnel.
>>
>> Just my 2 cents...
>>
>> Pierre
>>
>>
>>
>> Envoyé depuis mon smartphone Samsung Galaxy.
>>
>>  Message d'origine 
>> De : Stijn Rombauts via Talk-be 
>> Date : 27/05/19 20:57 (GMT+01:00)
>> À : OpenStreetMap Belgium 
>> Cc : Stijn Rombauts 
>> Objet : [OSM-talk-be] bridge or tunnel?
>>
>> Hi,
>>
>> 1. This is a bridge: no doubt.
>>
>> https://www.google.be/maps/@50.9628551,5.0810297,3a,75y,328.21h,89.12t/data=!3m6!1e1!3m4!1sXz43z9vWyUiOpCVTschIUQ!2e0!7i13312!8i6656?hl=nl
>>
>> 2. This is a tunnel: sure enough.
>>
>> https://www.google.be/maps/@50.6138142,5.5973887,3a,75y,97.64h,84.03t/data=!3m6!1e1!3m4!1sRvKwojNbhvMdSBWG3zViLw!2e0!7i13312!8i6656?hl=nl
>>
>> 3. This looks like a tunnel, no? Or is the fact that the railway is on an
>> embankment enough reason to make it a bridge?
>>
>> https://www.google.be/maps/@50.5508531,4.7216376,3a,89.9y,51.8h,87.45t/data=!3m6!1e1!3m4!1s4GoklQWnN5bW6ugdo1grmg!2e0!7i13312!8i6656?hl=nl
>>
>> 4. This one looks more like a bridge:
>>
>> https://www.google.be/maps/@50.5923923,4.6668939,3a,75y,57.67h,80.29t/data=!3m6!1e1!3m4!1s4y-C9gvI9ZsUk9jcNQX4eA!2e0!7i13312!8i6656?hl=nl
>>
>> 5. And this? Brunnel or tidge?
>>
>> https://www.google.be/maps/@50.5214486,4.8868137,3a,75y,27.85h,81t/data=!3m6!1e1!3m4!1sx0n9EuFTEx27S4sCQ--GPg!2e0!7i13312!8i6656?hl=nl
>>
>> 6. And if it gets shorter?
>>
>> https://www.google.be/maps/@50.5317414,4.9485687,3a,75y,39.18h,91.35t/data=!3m6!1e1!3m4!1sdTd6puiPIvGKsLBzeCzB6Q!2e0!7i13312!8i6656?hl=nl
>>
>> 7. And this?
>>
>> https://www.google.be/maps/@50.8660892,4.3648486,3a,75y,333.02h,85.73t/data=!3m6!1e1!3m4!1swvUHgLYhl8R5IXGVJ2QWiQ!2e0!7i13312!8i6656?hl=nl
>>
>> 8. A bit more complicated: not only a railway, but also the platforms on
>> a bridge? Or above a tunnel?
>>
>> https://www.google.be/maps/@50.8101922,4.3991964,3a,75y,63.96h,87.57t/data=!3m6!1e1!3m4!1s2ioHz72P7Ju0aTcMLalGKg!2e0!7i13312!8i6656?hl=nl
>>
>> 9. And if you turn around:
>>
>> https://www.google.be/maps/@50.8101922,4.3991964,3a,75y,258.54h,101.02t/data=!3m6!1e1!3m4!1s2ioHz72P7Ju0aTcMLalGKg!2e0!7i13312!8i6656?hl=nl
>>
>> I am curious about your opinion...
>> But of course, what those things are, is not really the question. How
>> should they be mapped? That's the question.
>>
>> Regards,
>>
>> StijnRR
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Importing polygons of administrative boundaries for Belgium into OSM

[Tim Couwelier]

Ground truth is only as precise as where they can manage to put up a sign
though.
I know a nearby case there a 3-point-border lies in the middle of an
intersection between two secondary roads.

Overruling an existing border just because the sign may be off a bit, seems
pushing it, no?

Op di 21 mei 2019 om 17:56 schreef joost schouppe :

> NGI data is not open as far as I'm aware. Cadastre is not accurate. You
> could look at Statbel nis9 open data. And for Flanders there is the
> "Voorlopig Referentiebestand Gemeentegrenzen", which is generally
> considered the best quality (note how it's called "voorlopig" though).
> So there is no single objective truth about where the borders are. As long
> as this situation persists (and it's Belgium so there is little reason to
> think this will be fixed soon), I don't see why OpenStreetMap should follow
> any of these sources closely. As long as this persists, looking at the
> different datasets (as well as some ground observations) with a human eye,
> seems the best way forward to me.
>
> --
> Joost Schouppe
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[OSM-talk-be] Weekly Riot chat digest - Volume 3 - 24/12/2018 - 30/12/2018

[Tim Couwelier]

Hi all.

New edition is up:
https://forum.openstreetmap.org/viewtopic.php?pid=732083#p732083
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[OSM-talk-be] Weekly Riot chat digest - Volume 2 - 17/12/2018 - 23/12/2018

[Tim Couwelier]

Hi all,

a bit later then usual (with the holidays and all):
https://forum.openstreetmap.org/viewtopic.php?pid=731339#p731339

(going with the link this time, as it was pointed out in most replies the
history is copied along, creating overly large e-mails)
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Weekly Riot chat digest - Please switch off copying the original!

[Tim Couwelier]

Point taken. Should it be desired among the mailing-list crowd, I could
just stick to sending a link to an external page with the info, rather then
including it all within the e-mail?
As a demo: Jonathan was kind enough to mirror it here:
https://openstreetmap.be/2018/12/17/weekly-riot.html


Op di 18 dec. 2018 om 09:51 schreef Hubert Christiaen <
hubert.christi...@telenet.be>:

> Colleagues,
>
> I received some long messages (28 Kb) containing only 2 lines of new
> information. Please switch of the copying of the original message when
> it is not needed as in this case. This is mostly an issue for users of
> Outlook, which copies the original message without showing it in the
> answer and in most cases thus without the sender noticing it.
>
> Sincerely,
> Hubert
>
> --
> Hubert Christiaen
> Bloesemlaan  17
> 3360 Korbeek-Lo
> Belgium
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[OSM-talk-be] Weekly Riot chat digest - Volume 1 - 10/12/2018 - 16/12/2018

[Tim Couwelier]

First of all, a short introduction. Based on discussion in chat, we feel
it'd be good to open up about what's discussed in the Riot (or IRC) chat
channel, and distribute a summary of it (on a weekly basis) through forum
and mailinglist. For now this is a one-man-operation, we'll see how it
evolves over time.

Input/feedback/extended discussion can be had through talk-be, the riot
channel or the belgian subsection of the openstreetmap.org fora.
(Note: I'm fully aware I'm probably a highly 'unknown' person to many
people within this mailinglist. I've talked through trying to do this with
Joost, and was met with his approval. If anyone has questions about me or
my part in this, do let me know.)







*Monday 10/12/2018*

Glenn informs about how to map a 'tractorsluis' (physical construction to
allow tractors to pass, but not normal cars).
https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dsump_buster

bxl-forever asks about how to map a certain type of barrier/fence.
fence_type = railing seems the best fit (
https://wiki.openstreetmap.org/wiki/Key:fence_type )

Seppe points out there's a Mapillary grant program for camera's.
Requires 50k+ uploaded pictures to be taken into consideration.
https://docs.google.com/forms/d/e/1FAIpQLScrPJcRGlh_FQCQCuZkk0tCK9317odk5RYeYfI2UruCzJW31Q/viewform

Jakka suggests supplying a basic simple template using osm-be tiles to
implement a map into a website.
Most agree this would be good, issue created on the osmbe-website github.


*Tuesday 11/12/2018*

Timcouwelier points out tiles are loading very slow,.
Escada confirms there's indeed issues, linking to the status page (
https://wiki.openstreetmap.org/wiki/Platform_Status )

Jakka asks about how to map mobil telephone antennae attached to power
towers.
Lionel_giard replies *'you only use
communication:mobile_phone/radio/...=yes/no for the transmission equipment.
The others tags are all for the structure. '*


*Wednesday 12/12/2018*

Timcouwelier asks about tagging suggestions for an entrace ramp to a
hospital with an overhead roof.
Tagging as a bridge seems an option, but would not match with using
'tunnel' for the covered part under the building + it's rendered overly
heavy. Consensus is to split the ramp and mark an  'incline = up' and
'incline = down', but to not  add percentage as it's unknown.
https://taginfo.openstreetmap.org/keys/incline#values apparantly shows 2
uses for 'incline = steep_as_hell'

Lionel_giard ask about how to map an 'internaat' (living quarters at school
for students not going home during the week).
This is a recurring question, but there's nothing beyond building =
residential. However, it should still clarify sufficient in combination
with amenity = school around it.

Timcouwelier asks about options in Overpass Turbo: building on a query that
selects all ways based on having a node last touched by a given user, is
there an option to do that for TWO users and style them differently?
Joost offers a workaround through mapcontrib, by using two layers with a
different query, and working with two different styles.

s8evq asks about possible missing attribution to OSM in the maps used by
postnl.be.
Contact is made based on the following input by Joost:
*If you want to deal with it yourself, add it to this list and write
them a message: *
*https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Websites#List_2*


A reply from wegspotter to a question by Glenn on 'slow roads', raises
discussion on how to deal with getting 'complete' info, as the requirements
for the vicinal ref (
https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Slowroads
) requires info that's not visible possible to retrieve in the field.

*Thursday 13/12/2018*

Discussion on the vicinal roads continues.
Neither atlas number, the vicinal_type (sentier vs chemin) can be found
without external sources.
Tim re-links the WMS for the atlas for most provinces, but before editing
them into the wiki, Joost plans to check to what extent they are 'within
license' to use as a source. Suggestion is made (by himself) to remind him
from time to time not to forget about this.

Discussion on the wiki status for the vicinal road tagging, raises issues
about communication of such wiki edits, where escada points out ideally
issues like that should get picked up either in riot channel or through the
mailing list. Timcouwelier adds that ideally, to keep discussion / progress
/ knowledge / information spread widely, it'd probably be a good idea to
created a weekly digest of what's discussed in the riot channel, both for
later reference but also to open up the discussions with those not actively
reading the channel.

That in mind, timcouwelier creates a framapad to start taking notes for a
weekly digest, to be sent to talk-be, and writes up a first prelimary
version for this week.

Lionel_giard asks about rendering status - it's still down, and there seem
to be more 

Re: [OSM-talk-be] Where to suggest/discuss the renderer?

[Tim Couwelier]

The problem is - whenever you try and get changes for the renderer - the
argument is they don't feel they should change the renderer to try and
influence the tagging. They care about rendering 'the tags that actively
get used'.

Be very carefull how you pitch the argument, or it'll instantly get a big
red 'denied' stamp on it merely based on that argument.

2018-02-23 8:22 GMT+01:00 marc marc :

> Le 23. 02. 18 à 07:44, Karel Adams a écrit :
> > Whence my repeated question: where or with whom can this be discussed?
>
> the tagging mailing for the schema
> https://lists.openstreetmap.org/listinfo/tagging
>
> github to use a current schema
> https://github.com/gravitystorm/openstreetmap-carto/
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Fwd: [OSM-talk] Highway=trunk : harmonization between countries ?

[Tim Couwelier]

There's always an inherit 'gap' between 'what does government intend the
road for' and 'how does the road actually look'.
Terms such as 'primary' and 'secondary' roads have meaning in planning
context.
In Flanders we have the 'Ruimtelijk Structuurplan Vlaanderen' which
classifies which roads are 'hoofdwegen' and which are primary (divided in
classes I and II)
Each Province has a 'Provinciaal Ruimtelijk Structuurplan', which
clasfficies which roads are secondary. (divided in classes I, II and III)
Each city/town is also supposed to have a 'Gemeentelijk Mobiliteitsplan'
which states which classification 'local' roads get, divided in classes I,
II and II)

There's potential for a very close match:

E and A roads are 'hoofdwegen'  => Tag as 'motorway'
The primary roads (regardless of their 'collecting' or 'connecting'
subtyping)  => tag as primary
The secondary roads (also regardless of their subtyping) => tag as secondary
The local roads types I and II => tag as tertiary
The local roads types III (aka 'the rest') => multitude of tagging options.

With the current tagging system and how it's applied in Belgium, we go
somewhere in between, but it's fairly 'clean' as it stands.
We don't look at what the government says, we go by 'how it looks' and link
that to the road numbering system for the' gewestwegen'.
Key point to decide on is if we SHOULD bother with 'intent' rather then
'reality', as 'mapping what's on the ground' is a basic principle.


Relating back to the post Joost distributed:
I do agree with most of the points, although 'trunk' is the odd part out.
'trunk' we don't use as a hierarchical classification, but to point out
it's a strech with a certain setup, i.e. forbidden for cyclists and such.


To end I'll repeat the example I've given in the riot channel about the
subtle difference between 'intended' and 'assumed':
The R32 ringroad around Roeselare.
Given it's a 'ringroad' it's classified in OSM as 'primary' all around.
But from the 'planning context' viewpoint, only the last stretches towards
the E403 are 'primary', and the majority is only 'secondary'. While the
road goes around Roeselare, it's function is to get people from and towards
the E403 'in either direction'. Due to the E403 being present, it's never
the intention to use the R32 to go around the entire end, as the E403 helps
cover that function.

PS:
If you have a look at said area, you'll also notice a part of 'trunk'.
Rendering wise, it 'feels' like the classification is different, and in
reality it looks different, but its function isn't really different at all.
Along with the aforementioned nuance primary/secondary, it's a second
example on how you could interpret on the same road.


2018-02-22 21:45 GMT+01:00 joost schouppe :

> Hi,
>
> Not wanting to change current consensus in Belgium, but I wonder how close
> this would be to current mapping practice in Belgium, and if it would be a
> way of thinking that could help in some current edge cases.
>
> -- Forwarded message --
> From: Fernando Trebien 
> Date: 2018-02-15 19:14 GMT+01:00
> Subject: Re: [OSM-talk] Highway=trunk : harmonization between countries ?
> To: t...@openstreetmap.org
>
>
> Landing on this discussion several months late. I've just heard of it
> by reading a wiki talk page [1].
>
> Since 13 February 2009, the wiki [2] criticises highway classification
> as problematic/unverifiable. This has also been subject to a lot of
> controversy (and edit wars) in my local community (Brazil), especially
> regarding the effect of (lack of) pavement.
>
> In trying to achieve greater consensus some years ago, I decided to
> seek opinions elsewhere and finally I arrived at this scheme [3] which
> I think is very useful, if not perfect yet. It can be easily
> summarised like this:
> - trunk: best routes between large/important cities
> - primary: best routes between cities and above
> - secondary: best routes between towns/suburbs and above
> - tertiary: best routes between villages/neighbourhoods and above
> - unclassified: best routes between other place=* and above
>
> For example, the best route between two villages would be at least
> tertiary. So would be the best route between a village and a town or a
> city. Parts of this route might have a higher class in case they are
> part of a route between more important places.
>
> It surely raises the problem of determining optimal routes. Maybe a
> sensible criterion would be average travel time without traffic
> congestion. A number of vehicles may be selected for this average -
> could be motorcycle+car+bus+truck, or simply car+truck.
>
> Early results in my area [4, in Portuguese] seem promising and have
> produced more consensus than any previous proposals. To me, this
> method seems to:
> - resist alternations in classification along the same road
> - work across borders (where classification discontinuities are
> expected because each country is 

Re: [OSM-talk-be] temporary cycle routes

[Tim Couwelier]

I'll go with a 'no' here.

Let me explain why:
Both the main routes (fietsostrade, fietssnelweg, whatever you wish to call
it) and the 'BFF' ('Bovenlokaal functioneel fietstroutenet) are by no means
an indication of actual infrastructure being present, nor is it a measure
of quality for the infrastructure that's there.
The point of a map is to show what's there. Neither BFF nor the structural
network of 'bike highways' are relevant in that aspect, they only show
where we'd eventually like to see proper infrastructure.

Don't get me wrong, if there's a suitable way to give the proper bike
highways a little lovin' on the map, I'm all for it. But only when it's
actually there.
Stretches that aren't  there, or that are on the BFF but the cycleways are
mapped as part of the other infrastructure there, probably shouldn't be
mapped as such.

Let me illustrate with an example, the connection 'Roeselare - Torhout',
along the train line:
- between Spoorweglaan and Mandeldreef the trajectory is drawn very badly.
- The stretch between Mandeldreef and Koning Leopold III-laan is yet to be
constructed (but at least building permit is in, afaik)
- Along the Regina Woutersweg there's so seperate bike infrastructure
- North of the Wijnendalestraat the bike path suddenly stops. The extension
of the currently present trajectory would run right across a (trucking)
transport company, and there's no opening in sight.
- it assumes a crossing below a bridge (R32), where there's no room between
the current road and train tracks (concrete bridge pillars in the way)
- the entire remaining stretch up to Stationsstraat in Gits is NOT THERE.
- 

How would one suggest mapping a such vision?



I will however state I'm in favor of covering the proper stretches through
relations, very much like the node networks, and what's on OpenCycleMap.
Sticking to 'mapping what's on the ground' would - to me - seem the best
way to go.
If there's clear intent on finishing missing links (like a piece in
Zwevegem, on the Guldensporenroute) could probably very early onwards get
mapped as 'under construction'.





2018-02-01 16:29 GMT+01:00 Ben Abelshausen :

> In London some of the routes are mapped as proposed, it's a bit annoying
> if you don't know that they are just proposed and not actually there:
>
> https://www.openstreetmap.org/relation/6691788
>
> Rendering is a dotted version of the normal line on the cycle layer:
>
> https://www.openstreetmap.org/#map=18/51.54524/-0.01871=C
>
> So, not sure if we should be mapping this if they don't exist yet... but
> if it's an 'official' detour why not? Some of these routes are only virtual
> anyway and not signed at all.
>
> Cheers,
> Ben
>
> On Thu, Feb 1, 2018 at 2:55 PM, joost schouppe 
> wrote:
>
>> Hi,
>>
>> I got an interesting question today. As the Flemish "fietsostrades"
>> (fietssnelwegen, or cycle highways) are taking shape, so they are being
>> mapped in OSM. People are already using the data, even though in reality,
>> this is till very much a project.
>>
>> In more and more places, parts are completely ready, but then just stop.
>> And in some cases, there is an "official detour" of the fietsostrade. So
>> while the infrastructure is not there yet, in a sense the route is already
>> there.
>>
>> How do you think this should be mapped, if at all?
>>
>> --
>> Joost Schouppe
>> OpenStreetMap  |
>> Twitter  | LinkedIn
>>  | Meetup
>> 
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] How to avoid that names are on all buildings

[Tim Couwelier]

Pitching in for a second, as it's my initial tag that got the ball rolling.

The name 'Clintonpark' indicates the combined area of the buildings and
their respective parkinglots, and is actually used as such.
It's not a 'street name', as the buildings have house numbers referencing
'Ter Reigerie', the street passing next to it.

At present, all the seperate buildings are tagged with the name
'Clintonpark', which is cluttered (and looks a bit messy), but isn't
entirely correct either.




2018-01-17 12:49 GMT+01:00 Marc Gemis :

> To answer how you have to map this, you first have to answer: what is
> "Clintonpark" ?
>
> - an area
> - a collection of buildings ?
> - a collection of identically named buildings ?
>
> m.
>
> On Wed, Jan 17, 2018 at 9:24 AM, Jakka  wrote:
> > Hi,
> >
> > Every building with a different house number is a office and named
> > "Clintonpark". Is this not to much same names on map.
> > I tried to put it in relations but validator do not liked it, building,
> > parking there are sharing same highways.
> > Is there a need solution.
> >
> > https://www.openstreetmap.org/note/1263904#map=17/50.95775/
> 3.10242=N
> >
> > thx
> >
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be