Re: [OSM-talk-be] Donation with tax certificate

[OSMDoudou via Talk-be]

Hello,

Do you know where we can read more about the procedure and conditions to 
receive approval by the KBF ?

Thx.



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

Re: [OSM-talk-fr] Banque de France

[OSMDoudou]

LOI n° 93-980 du 4 août 1993 relative au statut de la Banque de France et à 
l'activité et au contrôle des établissements de crédit

Art. 17. - Peuvent être titulaires de comptes à la Banque de France :
1° Les organismes régis par les dispositions de la loi n° 84-46 du 24 janvier 
1984 relative à l’activité et au contrôle des établissements de crédit ;
2° Le Trésor public, les services financiers de La Poste, l’institut d’émission 
des départements d’outre-mer, l’institut d’émission d’outre-mer et la Caisse 
des dépôts et consignations ;
3° Les sociétés de bourse régies par la loi n° 88-70 du 22 janvier 1988 sur les 
bourses de valeurs ;
4° Les banques centrales étrangères et les établissements de crédit étrangers ;
5° Les organismes financiers internationaux et les organisations 
internationales ;
6° Dans les conditions fixées par le Conseil général, les agents de la Banque 
de France, ainsi que toute autre personne titulaire de comptes de clientèle à 
la Banque de France à la date de publication de la présente loi ;
7° Tout autre organisme ou personne expressément autorisés par décision du 
Conseil général à ouvrir un compte à la Banque de France.

https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT00180850=id
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Relations pour établissement d'enseignement ?

[OSMDoudou]

From the wiki:
“
For schools with multiple sites the multipolygon relation can be used.
“
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dschool
https://wiki.openstreetmap.org/wiki/Relation:multipolygon

On May 17, 2019, at 11:42, deuzeffe  wrote:

Hello,

Soit un établissement d'enseignement, par exemple une école primaire, 
constituée d'une école maternelle sise dans un bâtiment dans une rue et d'une 
école élémentaire, sise dans un autre bâtiment trois rues plus loin. Cet 
établissement est identifié dans la base OD de l'EN comme une entité unique (un 
seul enregistrement avec une seule ref:UAI).

Est-ce qu'il est possible, faisable ou illusoire de bâtir une relation (de quel 
type ?) comprenant ces deux objets (au moins) ?

Merci pour vos réponses, quelles qu'elles soient.
-- 
deuzeffe, qui n'a pas dégainé JOSM pour y farfouiller :/

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

Re: [OSM-talk-fr] Dépose-minute

[OSMDoudou]

Les emplacements K qui me viennent à l'esprit sont signalés avec des panneaux P, ce qui fait penser qu'amenity=parking est approprié.


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

Re: [OSM-talk-fr] Les maternités ?

[OSMDoudou]

Pas certain...

amenity=hospital + healthcare=maternity ?
On 3/12/19, 09:30 Mathias Vadot  wrote:

  

  Bonjour, 

je n'ai pas trouvé le tag
  correspondant aux maternités sur les différentes pages du wiki. 

Sur Paris j'ai bien trouvé une
  maternité mais non taggué... des idées ? Mathias


  https://urlz.fr/990d

   
 
  
  Garanti sans virus. www.avast.com   
 

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


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

Re: [OSM-talk-fr] Les contours de la Bretagne

[OSMDoudou]

Sinon, on peut cartographier des mondes fictifs sur OpenGeoFiction... :-)

https://wiki.openstreetmap.org/wiki/OpenGeofiction___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ça veut dire quoi ça :

[OSMDoudou]

Concernant le mot de passe, il y a un avetissement clair lors de l’inscription: 
https://lists.openstreetmap.org/listinfo/talk-fr.

Bounce mail sont des situations d’erreur rencontrées par ton fournisseur de 
mail: https://en.m.wikipedia.org/wiki/Bounce_message.

Les raisons peuvent varier, comme par exemple, dépassement de quota de 
stockage, addresse mail invalide, serveur mail en erreur, etc.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Imprimer un plan à partir d'OSM ?

[OSMDoudou]

Est-ce que ceci est utile ?

 

  
https://wiki.openstreetmap.org/wiki/OSM_on_Paper

 

 

From: pepilepi...@ovh.fr [mailto:pepilepi...@ovh.fr] 
Sent: Wednesday, February 13, 2019 18:50
To: talk-fr@openstreetmap.org
Subject: [OSM-talk-fr] Imprimer un plan à partir d'OSM ?

 

Bonjour,

Pour son prochain plan sur papier la municipalité de mon patelin aimerait avoir 
un rendu d'OSM. L'imprimeur veut un fichier jpeg, tif ou PDF.

Quelqu'un pourrait-il m'expliquer comment faire ça SVP ? (ou m'indiquer une doc 
claire de préférence avec des exemples)

Je maitrise Python, je sais qu'il y a des API pour OSM, mais je n'y ai encore 
jamais touché.

Merci,

Jean-Pierre

-- 

  _  

Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la bonne 
question 

 

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

Re: [OSM-talk-fr] Cimetière militaire

[OSMDoudou]

Voir cette discussion récente sur les carrés confessionnels: 
https://lists.openstreetmap.org/pipermail/talk-fr/2018-December/091336.html.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Et OSM la dedans !

[OSMDoudou]

> Il y a déjà du cross-post Twitter > Mastodon sur le compte 
> https://fr.osm.social/@osm_fr

> Ce n'est pas parfait, mais ça permet d'avancer.

Pourquoi ne pas inverser le flux: poster sur Mastodon et reposter sur Twitter ?

C’est peut-être symbolique, mais ça permet de faire connaître le compte 
Mastodon et d’affirmer la source primaire d’activité.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Portillon : entrance, gate, barrier, autre ?

[OSMDoudou]

Dans le cas de barrier=entrance, il s’agit d’une ouverture, le passage est 
libre, il n’y a pas de barrière.

Je ne vois pas entrance=gate dans le wiki, et je trouverais ça bizarre parce 
qu’entrance decrit l’utilité de l’entrée, pas tellement son dispositif.

Donc, reste barrier=gate pour décrire le dispositif (voir les photos sur le 
wiki pour le tag le plus approprié).

La caméra peut être marquée avec “surveillance”.

Pour l’interphone, je ne sais pas. Je ne trouve que courtesy_phone mais c’est 
une proposition et pour le service au public: 
https://wiki.openstreetmap.org/wiki/Proposed_Features/Courtesy_Phone.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-be] arlon - osm - training courses

[OSMDoudou]

Thanks for the report.

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

Re: [OSM-talk-fr] "Give Box", Boîte à Dons

[OSMDoudou]

Il y a une proposition amenity=reuse: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Reuse.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-be] OSM.be versus OpenStreetMap.be

[OSMDoudou]

So, it's rather consistent. Thx for the check.


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

Re: [OSM-talk-be] OSM.be versus OpenStreetMap.be

[OSMDoudou]

It’s fine as long as it’s consistent and predictable for the user.

If a regional domain shows a map and another the chapter info, it can be 
confusing.

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

Re: [OSM-talk-be] OSM.be versus OpenStreetMap.be

[OSMDoudou]

Second thoughts...

When you visit a .com website, which also has an affiliated regional website, 
like .be, you expect to find the same stuff but in the local language and with 
local products.

By the logic above, openstreetmap.be should show the map centered on Belgium.

In the case of openstreetmap.org and openstreetmap.be, they would be totally 
different.

My 2ç.


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

Re: [Talk-transit] [Tagging] Public Transport Timetables

[OSMDoudou]

> Even if you can make it fit, it's not necessarily a good idea to do it.
> I'm thinking of the Hoover Dustette.

Excuse my ignorance. You’re thinking to what ?

> I'm not sure that a wiki would be the optimal architecture for this if we 
> ended up with many GTFS feeds that were interrogated frequently.

Problem solved already, it seems: http://transitfeeds.com.___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[OSMDoudou]

(Re-posting because I accidentally dropped talk-transit)

On Nov 8, 2018, at 00:30, OSMDoudou 
<19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:

Just a quick web search, but it appears there exist GTFS editors and there is 
an entire ecosystem around creating and hosting GFTS files. Here is one editor, 
for example: https://conveyal-data-tools.readthedocs.io/en/latest.___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[OSMDoudou]

(Re-posting because I accidentally dropped talk-transit)

On Nov 8, 2018, at 00:18, OSMDoudou 
<19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:

> And it's re-inventing the wheel.  GTFS already exists.
> Could we do better?  Maybe, maybe not.

Indeed. If someone determines GTFS needed improvement, it’s best to work in 
that community to improve it instead of inventing another standard. This xkcd 
comic is particularly well suited for this situation: https://xkcd.com/927/.

> We could perhaps encourage mappers to generate
> feeds where the operator doesn't provide them and maybe even
> go so far as to run a web server hosting those feeds until
> such time as a more official feed is available.

It’s very much what I have in mind as well.

We should think one step further than the tagging and figure a solution for 
maintaining and hosting GTFS files in case the PT organization doesn’t publish 
one. If we can resolve the issue of hosting the files, it will encourage OSM 
contributors to think more towards contributing to a web of data and less into 
“forcing” whatever geo-related data in OSM database.

And hosting these files doesn’t need to be complex. For example, certain JOSM 
plug-in’s have their configuration hosted in the wiki: 
https://josm.openstreetmap.de/wiki/Presets#JOSMwikiAvailablepresetpreferredmethod.
 So, we maybe already have the solution (with the OSM wiki, not the JOSM wiki).___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [OSM-talk-be] OSM.be versus OpenStreetMap.be

[OSMDoudou]

+1 



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

[OSM-talk-be] ING is using OpenStreetMap

[OSMDoudou]

Hello,

 

I incidentally found this.

 

Thanks to GDPR, we now know that ING is using OpenStreetMap internally:

- "ING also collects data by consulting external sources. These may be (.)
OpenStreetMap and other search engines in connection with marketing" [1]

- "Some specific personal data may be shared with service providers,
including (.) OpenStreetMap in the context of marketing" [2]

 

Not yet for their branch locator [3], but it's interesting to note already.

 

[1] https://www.ing.be/SiteCollectionDocuments/GeneralRegulationsNewEN.pdf

[2] https://www.ing.be/Assets/Documents/PrivacyStatementEN.pdf

[3] https://branches.ing.be/branches

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

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

[OSMDoudou]

I don't know the details of this particular case, but if there is a real 
intention to be built the route, then why not map it as future ?

 

OMS has tags to manage the life-cycle of past, present and future features.

 

 

From: Tim Couwelier [mailto:tim.couwel...@gmail.com] 
Sent: Thursday, February 1, 2018 18:17
To: OpenStreetMap Belgium 
Subject: Re: [OSM-talk-be] temporary cycle routes

 

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] [Tagging] Way access mismatch relation route=bicycle

[OSMDoudou]

Looking at signs on the ground [8] and legislation [9], R50 classifies as a 
primary road and not as a trunk, because agricultural vehicles are allowed, 
whereas the F9 road sign inherently forbids agricultural vehicles.

[8] https://goo.gl/maps/ft7Mf85AuM42
[9] https://www.permisdeconduire-online.be/snelwegwet2.htm

-Original Message-
From: Marc Gemis [mailto:marc.ge...@gmail.com] 
Sent: Friday, January 19, 2018 08:49
To: OpenStreetMap Belgium <talk-be@openstreetmap.org>
Subject: Re: [OSM-talk-be] [Tagging] Way access mismatch relation route=bicycle

We had a similar discussion on the ring around Roeselare on the Riot/Matrix 
channel.

Maybe it's time we rewrite the Belgian highway classification page to indicate 
that Nxxx & Rxxx are just indications for mapping and that traffic signs and 
road importance take precedence ?

m

On Fri, Jan 19, 2018 at 8:44 AM, OSMDoudou 
<19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
> Thanks for the link. I hadn't discovered this page yet.
>
> On the other hand, the same page reads "Rx should also be tagged as 
> motorways".
>
> R0 Brussels, R1 Antwerp and R4 Ghent are tagged like that.
>
> But R24 Nivelles, R20 Brussels, R9 Charleroi are tagged as trunks.
>
> And R52 Tournai, R36 Kortrijk and R30 Brugge as primary.
>
> And parts of R23 Leuven are tagged as primary and some other even as 
> secondary.
>
> So, it seems nuance, interpretations and findings from the ground lead to 
> different tagging of R roads.
>
> -Original Message-
> From: Marc Gemis [mailto:marc.ge...@gmail.com]
> Sent: Friday, January 19, 2018 07:16
> To: OpenStreetMap Belgium <talk-be@openstreetmap.org>
> Subject: Re: [OSM-talk-be] [Tagging] Way access mismatch relation 
> route=bicycle
>
> I think 
> https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Hi
> ghways gives the solution, there needs to be an F9 sign. If not, it is 
> a primary.
>
> regards
>
> m
>
> On Thu, Jan 18, 2018 at 10:24 AM, OSMDoudou 
> <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
>> Hello,
>>
>> Can you help with the B) part of the discussion ?
>>
>> What highway value is suitable for R50 ?
>>
>> Now that I discovered the local implicit characteristics thanks to 
>> the answer to question A), trunk is probably right, but I wanted to 
>> ask your views nonetheless.
>>
>> Thx.
>> 
>> From: Volker Schmidt
>> Sent: ‎18-‎01-‎18 09:39
>> To: Tag discussion, strategy and related tools
>> Subject: Re: [Tagging] Way access mismatch relation route=bicycle
>>
>> I suppose Osmose uses the country specific tables in [1] The table 
>> for Belgium states that bicycle=no is implicit for "highway=trunk".
>> Hence the short way in question would need to have the additional tag 
>> "bicycle=yes" for bicycle routing to pass along that cycle lane.
>> The road signs out there seem to be consistent, there are "no-bicycle"
>> sign along the ring road, except for this short piece.
>>
>> Your second point regarding the road classification trunk is a 
>> different issue, that needs to be discussed with the Belgian community.
>>
>> [1]
>> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restr
>> i
>> ctions
>>
>> On 17 January 2018 at 22:45, OSMDoudou 
>> <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
>>>
>>> Hello,
>>>
>>>
>>>
>>> This is a two-fold question in fact.
>>>
>>>
>>>
>>> (A)
>>>
>>>
>>>
>>> Osmose raises error "Way access mismatch relation route=bicycle" [1] 
>>> on a segment of the R50 highway [2] [3].
>>>
>>>
>>>
>>> I'm guessing it's because the segment is part of relation for a bike 
>>> route but it's tagged as trunk (as the rest of R50), and a trunk 
>>> would imply a restriction for bicycles.
>>>
>>>
>>>
>>> Although, I see such an implication for motorways [4], I don't see 
>>> it for trunks [5].
>>>
>>>
>>>
>>> Do you know what causes the access mismatch, because I don't see it 
>>> from the tags ?
>>>
>>>
>>>
>>> (B)
>>>
>>>
>>>
>>> This issue raises the question whether R50 should be tagged as trunk 
>>> in the first place.
>>>
>>>
>>>
>>> The Wiki page [6] refers to notions like "high performance" and road 
>>> signs F9. But the road i

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

[OSMDoudou]

I don't know for sure, but the rendering on openstreetmap.org is called 
OpenStreetMap Carto and to request improvement I think you file a bug report on 
their github. [1] See also [2] and notice the brief "Reporting Issues" guidance 
mentions providing a screenshot and a link. [2]

[1] https://github.com/gravitystorm/openstreetmap-carto/issues
[2] 
https://github.com/gravitystorm/openstreetmap-carto/blob/master/CONTRIBUTING.md

-Original Message-
From: Karel Adams [mailto:fa348...@skynet.be] 
Sent: Friday, January 19, 2018 16:43
To: OpenStreetMap Belgium 
Subject: [OSM-talk-be] Where to suggest/discuss the renderer?

When I first consulted maps - paper-only, at that time, of course - the famous 
Michelin 1:20 had distinct symbols for (bigger) airports,
(smaller) airfields, and glider fields. As of 2018, the generic map of 
openstreetmap has only a single icon to represent anything mapped with 
"aeroway:aerodrome" - and all of them rendered as from zoomlevel=13 - and none 
below.

This is really very bad. Why should I want to contribute to a system that 
delivers poorer info than paper maps of 50 years old?

Even worse, many active and able mappers are reluctant to update the database 
properly because the correct info will be so poorly rendered. 
Especially in France and Italy, where I had endless arguments with people 
removing the "aeroway=aerodrome" tag from real proper aerodromes, because they 
didn't want their local grass runway mapped the same as CDG Roissy airport. 
Even if I don't agree, I can fully understand their point of view!

What is the proper place to question this matter, and discuss schemes of 
improvement? Is there a discussion site for the renderer?




___
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] Way access mismatch relation route=bicycle

[OSMDoudou]

Thanks for the link. I hadn't discovered this page yet.

On the other hand, the same page reads "Rx should also be tagged as motorways".

R0 Brussels, R1 Antwerp and R4 Ghent are tagged like that.

But R24 Nivelles, R20 Brussels, R9 Charleroi are tagged as trunks.

And R52 Tournai, R36 Kortrijk and R30 Brugge as primary.

And parts of R23 Leuven are tagged as primary and some other even as secondary.

So, it seems nuance, interpretations and findings from the ground lead to 
different tagging of R roads.

-Original Message-
From: Marc Gemis [mailto:marc.ge...@gmail.com] 
Sent: Friday, January 19, 2018 07:16
To: OpenStreetMap Belgium <talk-be@openstreetmap.org>
Subject: Re: [OSM-talk-be] [Tagging] Way access mismatch relation route=bicycle

I think 
https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Highways
gives the solution, there needs to be an F9 sign. If not, it is a primary.

regards

m

On Thu, Jan 18, 2018 at 10:24 AM, OSMDoudou 
<19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
> Hello,
>
> Can you help with the B) part of the discussion ?
>
> What highway value is suitable for R50 ?
>
> Now that I discovered the local implicit characteristics thanks to the 
> answer to question A), trunk is probably right, but I wanted to ask 
> your views nonetheless.
>
> Thx.
> 
> From: Volker Schmidt
> Sent: ‎18-‎01-‎18 09:39
> To: Tag discussion, strategy and related tools
> Subject: Re: [Tagging] Way access mismatch relation route=bicycle
>
> I suppose Osmose uses the country specific tables in [1] The table for 
> Belgium states that bicycle=no is implicit for "highway=trunk".
> Hence the short way in question would need to have the additional tag 
> "bicycle=yes" for bicycle routing to pass along that cycle lane.
> The road signs out there seem to be consistent, there are "no-bicycle" 
> sign along the ring road, except for this short piece.
>
> Your second point regarding the road classification trunk is a 
> different issue, that needs to be discussed with the Belgian community.
>
> [1]
> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restri
> ctions
>
> On 17 January 2018 at 22:45, OSMDoudou 
> <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
>>
>> Hello,
>>
>>
>>
>> This is a two-fold question in fact.
>>
>>
>>
>> (A)
>>
>>
>>
>> Osmose raises error "Way access mismatch relation route=bicycle" [1] 
>> on a segment of the R50 highway [2] [3].
>>
>>
>>
>> I'm guessing it's because the segment is part of relation for a bike 
>> route but it's tagged as trunk (as the rest of R50), and a trunk 
>> would imply a restriction for bicycles.
>>
>>
>>
>> Although, I see such an implication for motorways [4], I don't see it 
>> for trunks [5].
>>
>>
>>
>> Do you know what causes the access mismatch, because I don't see it 
>> from the tags ?
>>
>>
>>
>> (B)
>>
>>
>>
>> This issue raises the question whether R50 should be tagged as trunk 
>> in the first place.
>>
>>
>>
>> The Wiki page [6] refers to notions like "high performance" and road 
>> signs F9. But the road is limited to 70 km/h and there are no F9 
>> signs on the entries and exits of R50, only C19 "No entry for 
>> pedestrians" and C11 + C9 "No entry for bicycles" + "No entry for 
>> mopeds (and mofas)", which tend to confirm it's not a trunk.
>>
>>
>>
>> I wonder if primary wouldn't be more accurate classification, 
>> although the Wiki refers to a "highway linking large towns" [7], 
>> which is not the case here as the highway is a ring around the city not a 
>> road between cities.
>>
>>
>>
>> What type of road would you qualify the entire R50 ?
>>
>>
>>
>> Thx.
>>
>>
>>
>> [1] http://osmose.openstreetmap.fr/en/error/15216104253
>>
>> [2] http://www.openstreetmap.org/browse/way/251684307
>>
>> [3] https://goo.gl/maps/khpwvm8kxQw
>>
>> [4] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway
>>
>> [5] https://wiki.openstreetmap.org/wiki/Trunk
>>
>> [6] https://wiki.openstreetmap.org/wiki/Road_signs_in_Belgium
>>
>> [7] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dprimary
>>
>>
>> ___
>> Tagging mailing list
>> tagg...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> ___
> 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] [Tagging] Way access mismatch relation route=bicycle

[OSMDoudou]

Hello,

Can you help with the B) part of the discussion ?

What highway value is suitable for R50 ?

Now that I discovered the local implicit characteristics thanks to the answer 
to question A), trunk is probably right, but I wanted to ask your views 
nonetheless.

Thx.


-Original Message-
From: "Volker Schmidt" <vosc...@gmail.com>
Sent: ‎18-‎01-‎18 09:39
To: "Tag discussion, strategy and related tools" <tagg...@openstreetmap.org>
Subject: Re: [Tagging] Way access mismatch relation route=bicycle

I suppose Osmose uses the country specific tables in [1]

The table for Belgium states that bicycle=no is implicit for "highway=trunk".

Hence the short way in question would need to have the additional tag 
"bicycle=yes" for bicycle routing to pass along that cycle lane.

The road signs out there seem to be consistent, there are "no-bicycle" sign 
along the ring road, except for this short piece.


Your second point regarding the road classification trunk is a different issue, 
that needs to be discussed with the Belgian community.


[1] https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions



On 17 January 2018 at 22:45, OSMDoudou 
<19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:

Hello,
 
This is a two-fold question in fact.
 
(A)
 
Osmose raises error "Way access mismatch relation route=bicycle" [1] on a 
segment of the R50 highway [2] [3].
 
I'm guessing it's because the segment is part of relation for a bike route but 
it's tagged as trunk (as the rest of R50), and a trunk would imply a 
restriction for bicycles.
 
Although, I see such an implication for motorways [4], I don't see it for 
trunks [5].
 
Do you know what causes the access mismatch, because I don't see it from the 
tags ?
 
(B)
 
This issue raises the question whether R50 should be tagged as trunk in the 
first place.
 
The Wiki page [6] refers to notions like "high performance" and road signs F9. 
But the road is limited to 70 km/h and there are no F9 signs on the entries and 
exits of R50, only C19 "No entry for pedestrians" and C11 + C9 "No entry for 
bicycles" + "No entry for mopeds (and mofas)", which tend to confirm it's not a 
trunk.
 
I wonder if primary wouldn't be more accurate classification, although the Wiki 
refers to a "highway linking large towns" [7], which is not the case here as 
the highway is a ring around the city not a road between cities.
 
What type of road would you qualify the entire R50 ?
 
Thx.
 
[1] http://osmose.openstreetmap.fr/en/error/15216104253
[2] http://www.openstreetmap.org/browse/way/251684307
[3] https://goo.gl/maps/khpwvm8kxQw
[4] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway
[5] https://wiki.openstreetmap.org/wiki/Trunk
[6] https://wiki.openstreetmap.org/wiki/Road_signs_in_Belgium
[7] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dprimary

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