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

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

Re: [OSM-talk-be] Request to change the cycle highway network tag

[s8evq]

 I think the arguments of Minh Nguyễn are valid.  It wouldn't be a big deal to 
change cycle_network=cycle_highway to cycle_network=BE:cycle_highway for 
example (or to cycle_network=BE:fietssnelweg). I would additionally also add 
cycle_highway=yes. 

On Tue, 6 Oct 2020 20:53:06 +0200, Pieter Vander Vennet  
wrote:

> Hello everyone,
> 
> Minh NGuyen had the following remark on the wiki
> 
> about the current tagging scheme of the cycle highways.
> 
> Anyone any thought on it?
> 
> 
> Incompatible with cycle_network
> 
> This tag is incompatible with the predominant usage of cycle_network
> =*. This key was
> originally intended to identify a specific network with uniform
> signage – a renderer was supposed to be able to choose a shield based on
> a combination of cycle_network
> =* and ref
> =*. But it appears that
> cycle highways are signposted and numbered differently in each country,
> so there's no such cycle network as "cycle highway":
> 
>   *
> 
> 
> 
> Belgium
> 
>   *
> 
> 
> Germany
> 
>   *
> 
> 
> 
> Netherlands
> 
> A renderer would have to perform a spatial query to reliably display the
> correct shield for each of these routes, somewhat undermining the push
> to have renderers use route relations instead of ref
> =* tags on ways.
> 
> We already made this mistake once by repurposing the network
> =lcn/rcn/ncn tags for
> routes outside the United Kingdom, leading to the otherwise redundant
> key cycle_network
> =* as a
> workaround. Let's avoid making this mistake again by deprecating
> cycle_network
> =cycle_highway
> 
> in favor of country-prefixed values like cycle_network
> =NL:cycle_highway
> ,
> or by choosing a different key altogether like cycle_highway
> =yes.
> 
> 
> – Minh Nguyễn  ^
>  00:51, 5
> October 2020 (UTC)
> 
> -- 
> Met vriendelijke groeten,
> Pieter Vander Vennet
> ___
> 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] IBPT antennas

[s8evq]

What is the point of adding longitude=* and latitude=* to the nodes?

How precise are the locations of the antennas in the BIPT dataset? Do we know 
what the quality of this data is before importing?

I agree that the data should be kept up to date through a script. If you don't 
keep it up to date, most likely nobody will ever verify or adjust it, as the 
antenna's are sometimes very difficult to see from the ground. 

Do you plan on posting your import proposal to the import mailing list, to get 
some more feedback?

Perhaps my questions sound a bit tough, but I appreciate the effort you put 
into this. 

On Sun, 8 Mar 2020 17:46:38 +, Karel Adams  wrote:

> Over de talenkwestie zeg ik maar niet teveel, enkel een "bravo" voor de 
> oproep tot objectiviteit.
> 
> Maar inhoudelijk heb ik wel zo mijn vragen: wij mappen toch "in 
> principe" enkel dingen die zichtbaar zijn in het landschap? Die antennes 
> van BIPT die hangen toch meestal op bestaande faciliteiten, hetzij een 
> mast die voor iets anders was opgezet, of een watertoren, een kerktoren, 
> of wat dan ook? Uiteraard mappen wij wel die masten en torens, maar om 
> de antennes als dusdanig te mappen? dat lijkt me strijdig met het 
> basisidee om enkel zichtbare landschapselementen te mappen.
> 
> No comments on the matter of languages, in this complicated and delicate 
> country; save for my compliment and support for the appeal for objectivity.
> 
> But regarding "the root of the matter" I do have my questions: didn't we 
> have a rule to map only those features visible in the scenery? The BIPT 
> antennae (sic!) are usually attached to existing structures, such as 
> church spires or GSM masts or so? Of course we map those highly visible 
> carrying structures, but to map the individual antennae seems to me like 
> overdoing things.
> 
> Karel
> 
> On 2020-03-08 16:55, Thibault Rommel wrote:
> > Hello there
> >
> > Small detail, I believe it makes more sense to use the abbreviation 
> > BIPT instead of IBPT, since it is "Belgian Institute for Postal 
> > services and Telecommunications" in English and both Dutch and German 
> > also have BIPT as the abbreviation.
> >
> > --
> > Thibault
> >
> > Op zo 8 mrt. 2020 om 14:16 schreef Vucodil via Talk-be 
> > mailto:talk-be@openstreetmap.org>>:
> >
> > Hello everyone,
> >
> > Recently, we got the permission from ibpt.be  to
> > use their data in OpenStreetMap:
> > 
> > https://wiki.openstreetmap.org/wiki/Import/Catalogue/ibpt_belgium_antennas
> > This includes all the antennas (more than 9000) managed by the
> > three operators (Proximus, Mobistar and Telenet) with the info on
> > who manages which antennas and their localisation.
> >
> > I wish to import them in a semi-automatic import. But before that,
> > I wish to have your feedback on the:
> >
> > *General workflow*
> >
> > For the workflow, you can find it at the end of the import wiki
> > page. The main idea is that the antennas to close to existing
> > antennas will be manually reviewed.
> > What do you think about that? Is it safe enough?
> >
> > *Tags to use*
> >
> > As there is around 300 antennas currently in Belgium
> > (https://overpass-turbo.eu/s/QPC) and considering that this import
> > will bring more than 9000 antennas, I think the tags of the import
> > should be carefully chosen.
> > The tags for the objects related to telecoms are not well defined.
> > Various sources of information are available (see at the end of
> > this email).
> > If we choose to only map the antenna itself by excluding the
> > support (mast, tower, roof, ...), it seems to exist two tags:
> >
> > - man_made=antenna
> > (https://taginfo.openstreetmap.org/tags/man_made=antenna#overview)
> > - telecoms=antenna
> > (https://taginfo.openstreetmap.org/tags/?key=telecom=antenna)
> >
> > the first one being much more used. That's the one that I suggest.
> > You can see more details on the tagging here:
> > 
> > https://wiki.openstreetmap.org/wiki/Import/Catalogue/ibpt_belgium_antennas#Data_Preparation
> >
> > With the data from IBPT, it make sense to only focus on the
> > antenna itself and not on the support as we don't have any
> > information on it.
> > In cities, it will usually be on roofs or underground like in
> > tunnels but in the countryside, it is often on communication towers.
> >
> > Mapping only the antenna enable us to later map more complex
> > things like in this proposal
> > 
> > https://wiki.openstreetmap.org/wiki/File:Radio_antennas_mapping_proposal.png
> > 
> > 
> > where I really like the separation between:
> >
> > - antenna
> > - support
> > - station
> >
> > Note that today, most antennas in Belgium are mapped via their
> > support (mast or tower).
> >
> >

Re: [OSM-talk-be] RFC: explicit tagging of 'Jaagpaden'

[s8evq]

Hi Pieter,

So to be clear, you want to tag the historic usage of a road as a towpath? 

As a way of finding pleasant cycle ways, it's probably mostly valid. Two things 
I think about:

For example, this (https://www.mapillary.com/map/im/r1iBEQmaUlqv0BHGmDoIGw) 
would also classify as historic tow path. There is no cycle lane and cars can 
drive 50. (even 70 on the other side of the canal, before the crossroad).

On the other hand, the paths along the Albertkanaal wouldn't fit under a 
historic definition of towpath, as the canal was finished 1946 and the paths 
were most likely not used or intended to tow boats by.

What would be the criteria for this kind of road? Be parallel along a canal 
that historically had tow boats traffic?


On Tue, 3 Mar 2020 16:28:15 +0100, Pieter Vander Vennet  
wrote:

> Hey Marc,
> 
> Thanks for your response.
> 
> IMHO all towpaths are indeed peculiar service roads, thus
> 'highway=service' + 'service=towpath'. The wiki even mentions explicitly
> that it should be a service road.
> 
> The examples you sent are excellent examples where the legal signposting
> didn't catch up with the historic usage. These clearly used to be
> towpath but they didn't gain the legal recognition of a 'jaagpad'.
> Personally, I would tag those with 'service=towpath' (reflecting the
> historic usage) but not with 'towpath=yes', but this is very subject to
> change. We might even consider `towpath=no` (with a note clarifying this
> is legally _not_ a 'jaagpad') or `legal:towpath=no` or something similar.
> 
> Another thought: if we are about using 'towpath=yes' to reflect the
> legal status, I'm doubting that there is no better tag scheme for this.
> 
> 
> Kind regards, Pieter
> 
> 
> On 03.03.20 16:12, Marc Gemis wrote:
> > I'm fine with explicitly mapping them.
> > Isn't service=towpath strange on a way that is not tagged as
> > highway=service? (but you know that I think they should have been
> > mapped as highway=service in the first place, but this is not the
> > case)
> >
> > So it's meant for all those that are explicitly signed as "Jaagpad"
> > and not for any others? So this
> > https://www.mapillary.com/map/im/3T0U_uBJxNXHfrgwdztQDQ is not a
> > Jaagpad? (a bit further
> > https://www.mapillary.com/app/?lat=51.05439739997222=4.4334043=17=photo=cmVJ5z_VXnZqwsdrEK0aHw
> > , but that still does not make it a Jaadpad?)
> >
> > m.
> >
> > On Tue, Mar 3, 2020 at 2:14 PM Pieter Vander Vennet
> >  wrote:
> >> Hello everyone,
> >>
> >> Even though the legal restrictions of 'Jaagpaden' (towpaths in proper 
> >> English) is already described in detail on the wiki, it would still be 
> >> useful to reflect the special status explicitly, in our case to give a 
> >> comfort bonus in cycling route planning but also for historical purposes.
> >>
> >> For context, a 'jaagpad', 'trekpad' or towing path is a path that used to 
> >> be used to (literally) tow boats through the canals, either with manpower 
> >> or horsepower and a rope attached to the boat - hence there are never 
> >> trees between a towpath.
> >>
> >> With the rise of cheap and powerful combustion engines, this practice 
> >> became disused and towpaths became service roads and cycleways.
> >>
> >> As stated, these often are excellent and heavily preferred by cyclists. 
> >> Normally, they are wide, asphalted, there are very few cars and 
> >> especially: there is the very nice scenery of the canal.
> >>
> >> Therefore, I would propose to introduce tagging in Belgium to tag towpaths.
> >>
> >>
> >> There are two ways to achieve this:
> >>
> >> - A towpath is typically a specific type of service road, so we can add 
> >> `service=towpath`
> >>
> >> - In the UK, the towpaths are tagged with `towpath=yes`
> >>
> >> Note that towpaths in Flanders are mostly signposted with an official 
> >> sign, even though that this is a bit of a legal remnant of a previous era. 
> >> However, it makes it very explicit and thus unambiguous to map.
> >>
> >> But now, for the serious questions:
> >>
> >> - what are your thoughts of mapping them somehow? IMHO it is an added 
> >> value and I'm quite in favour of them.
> >>
> >> - What is the best way of mapping them? I'm a bit on the edge of the 
> >> options above: `service=towpath` is IMHO semantically the most correct 
> >> form, as it indicates that it is a service road originally built for 
> >> towing. `towpath=yes` reeks more of the legal status (i.e. having a formal 
> >> road sign indicating 'jaagpad'). The latter has the advantage of already 
> >> being in use in the UK with over 3500 instances according to taginfo. 
> >> service=towpath is not in use at the moment.
> >>
> >>
> >> PS: fun etymological fact: the English verb 'to tow' is derived from the 
> >> Dutch word for rope: 'touw'
> >>
> >> --
> >> Met vriendelijke groeten,
> >> Pieter Vander Vennet
> >>
> >> ___
> >> Talk-be mailing list
> >> Talk-be@openstreetmap.org
> >> 

Re: [OSM-talk-be] Tagging proposal for cycling highways (Fietssnelwegen)

[s8evq]

Actually, after reading the wiki pages, `cycle_network=BE:cycle_highway` seems 
indeed the best choice here.

On Tue, 10 Dec 2019 19:45:39 +0100 (CET), "s8evq"  wrote:

> On Tue, 10 Dec 2019 18:35:51 +0100, Pieter Vander Vennet 
>  wrote:
> 
> > *Tagging scheme*
> > 
> > I'd actually go for `cycle_network=BE:cycle_highway`, as cycle_network
> > normally has a country prefix. Because most (all?) of them are already
> > tagged, we could simply update the tagging all at once.  I'll do that
> > next week, unless a better proposal or good reason not to is raised.
> 
> 
> Concerning the tagging, would perhaps the new tag "network:type" be of any 
> help? https://wiki.openstreetmap.org/wiki/Key:network:type It was invented 
> for the use with value node_network, but could perhaps take other values?
> 
> If we can be critical? What makes a "Fietssnelweg" different from another 
> long distance route like LF5 https://www.openstreetmap.org/relation/5285 Only 
> the operator key?
> 
> ___
> 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] Tagging proposal for cycling highways (Fietssnelwegen)

[s8evq]

On Tue, 10 Dec 2019 18:35:51 +0100, Pieter Vander Vennet 
 wrote:

> *Tagging scheme*
> 
> I'd actually go for `cycle_network=BE:cycle_highway`, as cycle_network
> normally has a country prefix. Because most (all?) of them are already
> tagged, we could simply update the tagging all at once.  I'll do that
> next week, unless a better proposal or good reason not to is raised.


Concerning the tagging, would perhaps the new tag "network:type" be of any 
help? https://wiki.openstreetmap.org/wiki/Key:network:type It was invented for 
the use with value node_network, but could perhaps take other values?

If we can be critical? What makes a "Fietssnelweg" different from another long 
distance route like LF5 https://www.openstreetmap.org/relation/5285 Only the 
operator key?

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[s8evq]

Dag Stijn,

Wie zonder zonde is werpe de eerste steen:
http://osmose.openstreetmap.fr/en/byuser/StijnRR
Number of found issues: more than 500

Ik vind het not done om iemand zijn edits te dissecteren op een publieke 
mailinglist.

On Mon, 4 Nov 2019 15:31:34 + (UTC), Stijn Rombauts via Talk-be 
 wrote:

>  Even terug naar de aanpassingen van Jakka en ook wat aansluitend op 
> onderstaande opmerking van Marc. En ook omdat ik in alle stilte al wel wat 
> werk van Jakka heb verbeterd (en dan bedoel ik effectief: fouten 
> corrigeren):- parkeerplaatsen: Jakka heeft daar de individuele 
> parkeerplaatsen gemapt; op zich OK. Maar waarom een aantal wel en de andere 
> niet? En vergeet dan niet de amenity=parking (toegevoegd door Anakil): m.a.w. 
> zorg er op z'n minst voor dan eerst de grote lijnen in orde zijn, voeg pas 
> daarna de details toe (wiki: Mapping parking spaces is an addition, not a 
> replacement, to mapping a whole parking lot with amenity=parking.) Jakka had 
> trouwens een paar parkeerplaatsen foutief gemapt met amenity= parking. Daarna 
> heeft ene philippec binnen de amenity=parking van Anakil nog eens 2 keer een 
> amenity =parking toegevoegd (zoals deze 
> https://www.openstreetmap.org/way/741861188)...? Waarom?- nog 
> parkeerplaatsen: daar (https://www.openstreetmap.org/way/731154048) 3 brede 
> parkeerplaatsen getekend terwijl het er 5 smalle zijn...
> - https://www.openstreetmap.org/way/118797990: lanes=2 --> lanes=1, maar 
> turn:lanes=none|merge_to_left vergeten te verwijderen en ook 
> cycleway:right=lane vergeten te verwijderen
> - het gebruik van traffic_calming=island (volgens wiki: A structure 
> separating at least two lanes of a highway from each other for a short 
> distance.). Dan lijkt dat daar (aan het stukje Zemstbaan dat aansluit op de 
> Brusselsesteenweg) heel veel verkeerd gebruikt. Alleen al omdat die 'dingen' 
> daar niks met traffic calming te maken hebben, volgens mij.
> - een aantal fietspaden zijn apart bijgetekend (OK), maar waarom niet het 
> stukje langs de Zemstbaan van Zemstsesteenweg naar Brusselsesteenweg? De 
> oneway-tag lijkt mij ook een aantal keer te ontbreken. En ook de 
> bicycle=use_sidepath op de highways is niet toegevoegd...
> 
> Dat dingen in osm van jaren oud verbeterd, verfijnd of geüpdatet moeten 
> worden, is logisch. Maar dat recente veranderingen nog hopen extra werk 
> vragen omdat ze zeer onvolledig of ronduit fout zijn, vind ik behoorlijk 
> frustrerend. En met zo'n aanpassingen wordt de databank er ook echt niet 
> bruikbaarder op. Soit, 't is ook mijn eigen schuld omdat ik er anderen zelden 
> op aanspreek. En Jakka, jij bent zeker de ergste nog niet, verre van.
> StijnRR
> 
> Op maandag 4 november 2019 13:08:24 CET schreef Marc Gemis 
> :  
>  
>  > 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.
> 
> er is ook zoiets als "guerilla mapping"
> (http://sk53-osm.blogspot.com/2011/01/ive-been-guerilla-mapped.html)
> 
> m.
> 
> ___
> 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] tags for prohibitory road signs in Belgium

[s8evq]

On Wed, 25 Sep 2019 19:24:35 + (UTC), Stijn Rombauts via Talk-be 
 wrote:

Thanks Stijn for taking the time to comment.

> - An interesting change is the one from access=no/destination to 
> vehicle=no/destination for the
> C5-sign, which I support, because it's more correct. But a disadvantage is 
> that e.g. access=no/destination
> shows on the map, but vehicle=no/destination not. Would the proposal to treat 
> access=no/destination and
> vehicle=no/destination equally on the map make any chance?

On what map does it not display? I'm personally not in favor of using both 
tags. That makes it very confusing.


> Add C3 + 'uitgezonderd landbouwvoertuigen/landbouwgebruik/usage 
> agricole/convois agricoles... :
> vehicle=no + agricultural=yes- The same for bus=yes, taxi=yes, ... Or refer to
> https://wiki.openstreetmap.org/wiki/Key:access

OK, I added a link to access wiki page.

> 'uitgezonderd plaatselijk verkeer / excepté circulation locale' implies also 
> bus=yes

OK, it's added.


>  In the draft there is also a mistake: M4 and M5 cannot be added to a C1.

I removed those two images. It has no effect on the suggested tagging.

>  Another general remark: do not add access-tags which are already
> implied by the highway-tag that is used. In my opinion also the tags
> for the mandatory (D) signs should be reviewed. E.g. for D11 suffices
> highway=footway; all the rest is redundant. (And there are contradictions
> with this page: 
> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Belgium)

Sure, I agree. That could be a next project. Let's review the D signs with the 
default access restrictions in mind.


> Add examples for 'complicated' cases: e.g. 'C3+uitgezonderd plaatselijk 
> verkeer' i
> n one direction / no access limitations in the other direction.

To avoid repetition, perhaps it's better to refer to the access wiki page. In 
my view, this road_signs_in_Belgium page shouldn't try to explain everything.


> Is it a good idea to encourage mappers to add overtaking=yes wherever 
> overtaking is
>  not forbidden? I'd treat that as a default: no need to add that tag 
> explicitly.


I agree with you on that. No need for unnecessary tags. The wiki 
(https://wiki.openstreetmap.org/wiki/Key:overtaking) states indeed that yes is 
a default value. I'll remove the suggested tags.


Op maandag 16 september 2019 09:21:29 CEST schreef joost schouppe 
:


Hi,

s8evq has been consulting some heavy mappers about the "road signs in 
Belgium" wiki page, because it didn't seem to reflect how we actually map. 
There's a draft new page at 
https://wiki.openstreetmap.org/wiki/Talk:Road_signs_in_Belgium#Suggestion_for_an_update_of_the_prohibitory_signs

Feel free to comment here or on Riot if you think it can be further 
improved!

-- 

Joost SchouppeOpenStreetMap | 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