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

[djakk djakk]

Hello,

highway=trunk is very different between countries, in France it is used for
motorway-like roads (dual carriageway), so the same road is sometimes
highway=primary and sometimes highway=trunk (example with the N7 road :
http://www.openstreetmap.org/#map=13/46.6303/3.2700), whereas in England or
in Japan highway=trunk is used like a highway=super-primary tag even if the
road is a urban street or a classic road (example :
http://www.openstreetmap.org/#map=17/51.62060/-0.78353).

Should it be harmonized to the England standard ?



djakk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[djakk djakk]

Hello Colin,

I'm from Brittany, west part of France :)

There is an equivalent of the "autoweg" sign in France. It is also tagged
with motorroad=yes.
https://fr.m.wikipedia.org/wiki/Panneau_d%27indication_d%27une_route_à_accès_réglementé_en_France
<https://fr.m.wikipedia.org/wiki/Panneau_d%27indication_d%27une_route_%C3%A0_acc%C3%A8s_r%C3%A9glement%C3%A9_en_France>

So I was thinking using "highway=trunk" for strategic roads, not only for
motor roads, all over the world ...
For example in the Netherlands :
https://www.openstreetmap.org/#map=14/51.8977/4.2042 the N57, primary
highway between a trunk and a motorway, becomes trunk in the new tagging
system ...
An other example, each European road which is not a motorway should be
tagged as a trunk road , it is not currently the case in France :
https://www.openstreetmap.org/way/42344655#map=15/46.4275/0.6306


djakk

Le ven. 18 août 2017 à 22:43, Colin Smale <colin.sm...@xs4all.nl> a écrit :

> In the UK it is a specific road class, with its own style of signage. So
> it is easily verifiable whether a road is a Trunk Road or not. Some Trunk
> Roads are motorway-like, but others are standard two-way roads. So actually
> it is not so much linked to the construction of the road, but to the fact
> that the route is part of the government's strategic route network.
>
> In most/many other countries this distinction does not exist, so the use
> of highway=trunk may become subjective unless a suitable definition is
> found. For example, in the Netherlands an "autoweg" is usually mapped to
> highway=trunk. These roads are indicated by a standard sign which you may
> recognise (I don't know where you come from I'm afraid):
>
>
> https://nl.wikipedia.org/wiki/Autoweg#/media/File:Nederlands_verkeersbord_G3.svg
>
>
> //colin
>
> On 2017-08-18 22:00, djakk djakk wrote:
>
> Hello,
>
> highway=trunk is very different between countries, in France it is used
> for motorway-like roads (dual carriageway), so the same road is sometimes
> highway=primary and sometimes highway=trunk (example with the N7 road :
> http://www.openstreetmap.org/#map=13/46.6303/3.2700), whereas in England
> or in Japan highway=trunk is used like a highway=super-primary tag even if
> the road is a urban street or a classic road (example :
> http://www.openstreetmap.org/#map=17/51.62060/-0.78353).
>
> Should it be harmonized to the England standard ?
>
>
>
> djakk
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[djakk djakk]

"strategic" may not be the right word (my english is rusty :) )

The thing is, I want to avoid those dotted highway=trunk like this :
https://www.openstreetmap.org/#map=13/48.5884/-1.4035 (trunk then primary
in the town then trunk again), I'd prefer trunk - still trunk in the town -
trunk, like in England :
https://www.openstreetmap.org/#map=14/51.1057/-2.1245

2017-08-19 14:00 GMT+02:00 Greg Troxel :

>
> Colin Smale  writes:
>
> > Interesting approach, which might work for Europe, but at the moment I
> > am not entirely convinced. What is strategic at a European level might
> > not be so strategic locally, and vice versa. The European numbers are
> > also not signposted everywhere, so there may be a challenge of
> > verifiability. I believe the European definition basically defines the
> > endpoints and a few waypoints, and it is left to national authorities to
> > join the dots as they wish. So it may or may not achieve your goal of
> > having a harmonised definition between countries.
>
> I agree with caution in trying to change anything.
>
> "Strategic" is an imprecise term.   In the US, different people have
> different opinions about which roads are important, depending on where
> they live and where they want to drive.
>
> The tagging scheme is very much the UK system, and has adapations in
> other countries.  In the US, motorway/interstate is easy, and we more or
> less have primary for US highways, secondary for state highways, and
> tertiary for the next level of importance (reaching adjacent population
> centers).
>
> In the US, "trunk" is fairly well defined.  It's a road that is
> substantially more than a regular highway in that it has some aspects of
> a motorway.  To be "motorway" (interstate class), the road needs to be
> divided, multiple lanes, no stoplights, no at-grade intersections, with
> controlled access.  To be trunk, the road has to be part way to that
> standard.  So that means that almost all trunks are divided with
> multiple lanes in each direction, but they typically have some
> intersections (every few miles to maybe every mile), and may have some
> but not a lot of non-ramp access.  They often have narrower lanes than
> Interstate specifications allow.
>
> Around me, the poster child for trunk is Route 2.  It's the second most
> important east-west road in Massachusetts,, and in many places has two
> lanes each way, is divided, and has occasional farmstands and roads on
> the edge, but fairly few.  Lights (and one rotary) are at least a mile
> apart, and sometimes 5ish miles apart.  But, way out west, it is no
> longer trunk - it's just ~Main street, undivided, one lane each way,
> lights, houses.  There it's highway=primary, because it's still a key
> route, as important as a US highway.  In some places it meets motorway
> specs and is tagged as such.
>
> Calling a regular highway trunk, when it should be secondary or primary
> would defeat the purpose of trunk, which is to identify roads that feel
> intermediate between regular US highway and Interstate.   We don't have
> any formal designation between US highway and Interstate.
>
> In addition, there's history of people wanting to retag highways to
> match their own view of these tags, and many others being unhappy about
> this.  This is hugely important in OSM, which is about a group of people
> cooperating to improve the map.
>
> > Are you actually sure there is a problem to be solved? Do you have
> > examples of inappropriate or inconsistent use of highway=trunk?
>
> That's a very good question.   Certainly I find cases where roads are
> over or under tagged, and as long as it's occasional, I just fix them to
> match the norms of the larger surrounding area.   This is very different
> from trying to make large-scale changes in what the tags mean.
>
> Perhaps the OPs could rephrase the discussion in terms of what seems
> wrong with actual tagging and how that impacts users of the database
> (not any particular render :-).
>
> All that said, a problem in OSM is the blurring of road classification
> and road characteristics.  But that partially reflects a larger societal
> blurring in terms of how people identify and use roads.   It partially
> reflects a choice made by renderers to emphasize classification.
> Imagine a map where colors depend on whether the road is divided, how
> many lanes it has, and intersection frequency, and aren't affected by
> government labels!
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[djakk djakk]

In England and Japan, trunk roads continue inside village boundaries.
https://www.openstreetmap.org/#map=16/52.2685/0.7700 ;
https://www.openstreetmap.org/#map=16/35.6261/139.1128
Trunk is used as a super-primary class of roads.

I think it is better to try to harmonize between countries, and to use the
English model all over the world than the one with the motor road sign. The
latter model can still exist thanks to motorroad=yes.


djakk

Le sam. 19 août 2017 à 21:29, Marc Gemis <marc.ge...@gmail.com> a écrit :

> As you can see from
> https://wiki.openstreetmap.org/wiki/Highway:International_equivalence,
> trunk roads are defined differently in many countries. If you look at
> e.g. Denmark, a trunk road needs a special sign. Those signs typically
> come with some rules and permissions (e.g. higher speed allowed, no
> pedestrians). In many cases there will be "end-of-trunk-roads" signs
> at town boundaries. This means that the trunk road effectively ends
> there.
>
> So trunk roads are more about physical characteristics and traffic
> signs and less about their importance in the road network. The same is
> more or less true for motorways.
>
> I see no reason why a trunk road has to continue inside village
> boundaries, where the maxspeed is e.g. limited to 50.
>
> regards
>
> m
>
>
>
> On Sat, Aug 19, 2017 at 5:30 PM, djakk djakk <djakk.dj...@gmail.com>
> wrote:
> > "strategic" may not be the right word (my english is rusty :) )
> >
> > The thing is, I want to avoid those dotted highway=trunk like this :
> > https://www.openstreetmap.org/#map=13/48.5884/-1.4035 (trunk then
> primary in
> > the town then trunk again), I'd prefer trunk - still trunk in the town -
> > trunk, like in England :
> > https://www.openstreetmap.org/#map=14/51.1057/-2.1245
> >
> > 2017-08-19 14:00 GMT+02:00 Greg Troxel <g...@lexort.com>:
> >>
> >>
> >> Colin Smale <colin.sm...@xs4all.nl> writes:
> >>
> >> > Interesting approach, which might work for Europe, but at the moment I
> >> > am not entirely convinced. What is strategic at a European level might
> >> > not be so strategic locally, and vice versa. The European numbers are
> >> > also not signposted everywhere, so there may be a challenge of
> >> > verifiability. I believe the European definition basically defines the
> >> > endpoints and a few waypoints, and it is left to national authorities
> to
> >> > join the dots as they wish. So it may or may not achieve your goal of
> >> > having a harmonised definition between countries.
> >>
> >> I agree with caution in trying to change anything.
> >>
> >> "Strategic" is an imprecise term.   In the US, different people have
> >> different opinions about which roads are important, depending on where
> >> they live and where they want to drive.
> >>
> >> The tagging scheme is very much the UK system, and has adapations in
> >> other countries.  In the US, motorway/interstate is easy, and we more or
> >> less have primary for US highways, secondary for state highways, and
> >> tertiary for the next level of importance (reaching adjacent population
> >> centers).
> >>
> >> In the US, "trunk" is fairly well defined.  It's a road that is
> >> substantially more than a regular highway in that it has some aspects of
> >> a motorway.  To be "motorway" (interstate class), the road needs to be
> >> divided, multiple lanes, no stoplights, no at-grade intersections, with
> >> controlled access.  To be trunk, the road has to be part way to that
> >> standard.  So that means that almost all trunks are divided with
> >> multiple lanes in each direction, but they typically have some
> >> intersections (every few miles to maybe every mile), and may have some
> >> but not a lot of non-ramp access.  They often have narrower lanes than
> >> Interstate specifications allow.
> >>
> >> Around me, the poster child for trunk is Route 2.  It's the second most
> >> important east-west road in Massachusetts,, and in many places has two
> >> lanes each way, is divided, and has occasional farmstands and roads on
> >> the edge, but fairly few.  Lights (and one rotary) are at least a mile
> >> apart, and sometimes 5ish miles apart.  But, way out west, it is no
> >> longer trunk - it's just ~Main street, undivided, one lane each way,
> >> lights, houses.  There it's highway=primary, because it's still a key
> >> route, as important as a US highway.  

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

[djakk djakk]

The thing is, I'm annoyed when there is a primary in the middle of a trunk
road (example : https://www.openstreetmap.org/#map=12/44.3996/-70.9439)
whereas in the U.K. this does not exist ... tagging rules should be as
generic as possible, should not they ?


djakk

Le mer. 23 août 2017 à 01:26, Greg Troxel <g...@lexort.com> a écrit :

>
> djakk djakk <djakk.dj...@gmail.com> writes:
>
> > Yes Martin, I meant "physical characteristics". In the US, a road is
> tagged
> > "trunk" according to its physical characteristics, as Greg said
> previously
> > in this thread.
>
> That's true, but it's also the case that the roads that are (properly)
> tagged trunk are also worthy of being tagged primary in importance to
> start with, plus becuase of the faster nature of trunk tend to be even a
> little more important.  So while choosing between primary/trunk is based
> on physical characteristics, it's not really in conflict with the notion
> of importance.  Basically you can view trunk as "primary with honors"
> and not be too far off.
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[djakk djakk]

I think there are five keys to tag a road :
1) its importance in the network (super-primary, primary, secondary ...)
2) its administrative class (motorway, mottorrad)
3) its physical characteristics (example : no at-grade intersections)
4) the width of its lanes
5) its surface


The current tagging system shuffles those 5 keys, "motorway" implies 2)
motorway signs 3) no at-grade intersections 4) large lanes 5) asphalt
surface, but for 1) it could be super-primary or just primary (think about
suburban motorways network).


djakk

Le mer. 23 août 2017 à 11:14, djakk djakk <djakk.dj...@gmail.com> a écrit :

> The thing is, I'm annoyed when there is a primary in the middle of a trunk
> road (example : https://www.openstreetmap.org/#map=12/44.3996/-70.9439)
> whereas in the U.K. this does not exist ... tagging rules should be as
> generic as possible, should not they ?
>
>
> djakk
>
> Le mer. 23 août 2017 à 01:26, Greg Troxel <g...@lexort.com> a écrit :
>
>>
>> djakk djakk <djakk.dj...@gmail.com> writes:
>>
>> > Yes Martin, I meant "physical characteristics". In the US, a road is
>> tagged
>> > "trunk" according to its physical characteristics, as Greg said
>> previously
>> > in this thread.
>>
>> That's true, but it's also the case that the roads that are (properly)
>> tagged trunk are also worthy of being tagged primary in importance to
>> start with, plus becuase of the faster nature of trunk tend to be even a
>> little more important.  So while choosing between primary/trunk is based
>> on physical characteristics, it's not really in conflict with the notion
>> of importance.  Basically you can view trunk as "primary with honors"
>> and not be too far off.
>>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[djakk djakk]

Oh yes I forgot these tags that are set by default by the highway key. Like
highway=motorway implies sidewalk=no (fun fact :  an exception does exist :
https://www.lyonmag.com/article/76367/le-pont-de-la-mulatiere-va-enfin-se-transformer-pour-les-cyclistes
: the signs says that the bridge is a motorway but it has a sidewalk)


djakk

Le mer. 23 août 2017 à 13:33, Martin Koppenhoefer <dieterdre...@gmail.com>
a écrit :

>
>
> sent from a phone
>
> On 23. Aug 2017, at 11:54, djakk djakk <djakk.dj...@gmail.com> wrote:
>
> I think there are five keys to tag a road :
> 1) its importance in the network (super-primary, primary, secondary ...)
> 2) its administrative class (motorway, mottorrad)
> 3) its physical characteristics (example : no at-grade intersections)
> 4) the width of its lanes
> 5) its surface
>
>
>
>
> not sure what you mean by "administrative class", but usually there aren't
> any problems deciding for the class "motorway" or the motorroad property
> (they are signed as such).
>
> Not sure about the width of lanes (probably there is something in lane
> tagging).
>
> You forgot many more tags that might be relevant for highway tagging, e.g.
> "width" (of the whole road), "lanes" (number of lanes), "lit", "oneway",
> access restrictions, tracktype for tracks, service for service roads,
> sidewalk as highway property, smoothness, maxspeed, maxheight, sac_scale,
> etc.
> Not all of them should be set on every road of course.
>
>
> cheers,
> Martin
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Name challenge - what to call the new OSM+Wikidata service?

[djakk djakk]

Wikidata+OSM as the long name, and w+OSM or wOSM as the short name ? :)

2017-09-16 23:11 GMT+02:00 Yuri Astrakhan :

> The new service is getting more and more usage, but it lacks the most
> important thing - a good name.  So far my two choices are:
>
> * wikosm
> * wikidosm
>
> Suggestions?  Votes?  The service combines Wikidata and OpenStreetMap
> databases, and uses SPARQL (query language) to search it, so might be good
> to reflect that in the name.
>
> https://wiki.openstreetmap.org/wiki/Wikidata%2BOSM_SPARQL_query_service
>
> P.S.  I know this is the hardest problem after off-by-one and caching...
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[djakk djakk]

Actualy, "highway=*" shuffles importance and characteristic of roads. May
we add an "importance" key to roads ?


djakk

Le dim. 20 août 2017 à 13:14, djakk djakk <djakk.dj...@gmail.com> a écrit :

> Well, it is technically possible, but I was thinking about performance and
> stylesheet-maintenance issues ;)
>
>
> Le dim. 20 août 2017 à 12:49, ajt1...@gmail.com <ajt1...@gmail.com> a
> écrit :
>
>> On 20/08/2017 11:36, djakk djakk wrote:
>> >
>> > Why I want to do that ? To improve openstreetmap, this is a worldwide
>> > map and the renderer can't be adapted by countries.
>> >
>>
>> Sure it can - it's perfectly possible for a render to use a
>> location-sensitive rendering (I've just done it myself).
>>
>> Best Regards,
>>
>> Andy
>>
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[djakk djakk]

Lester, why the little "main road" was not tagged as a tertiary road ?

I'm afraid that you can't use speed_limit : on small roads, the official
speed_limit is not signed but follows the default one (90km/h in France
even on a lanes=1.5 road !).

Le mar. 22 août 2017 à 11:16, Lester Caine <les...@lsces.co.uk> a écrit :

> On 21/08/17 21:09, djakk djakk wrote:
> > Actualy, "highway=*" shuffles importance and characteristic of roads.
> > May we add an "importance" key to roads ?
>
> Having spent the last week using OSMAND to navigate around the
> Welsh/Cheshire border area (UK ;) ), the 'importance' of roads is
> something of a problem even where the 'classification' of roads exists.
> Same problem in my own home area. OSMAND treats lower and unclassified
> roads as much lower importance when in many cases they ARE the main
> local route and this results in poor routing decisions! Importance can
> depend on why you are using the road? Things like 'speed_limit' need to
> be handled before adding another 'classification' tag?
>
> --
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[djakk djakk]

Yes Martin, I meant "physical characteristics". In the US, a road is tagged
"trunk" according to its physical characteristics, as Greg said previously
in this thread.


Le mar. 22 août 2017 à 11:06, Martin Koppenhoefer <dieterdre...@gmail.com>
a écrit :

>
>
> sent from a phone
>
> > On 21. Aug 2017, at 22:09, djakk djakk <djakk.dj...@gmail.com> wrote:
> >
> > Actualy, "highway=*" shuffles importance and characteristic of roads.
> May we add an "importance" key to roads ?
>
>
> highway is generally about grid importance and in some cases also about
> legal classification (motorways, footways etc.). "characteristic" is not
> something I understand in this context, maybe you mean "physical
> characteristics "? If so, then no. This was discussed and voted a long time
> ago and shouldn't be changed IMHO, as it has proven to work.
>
> cheers,
> Martin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[djakk djakk]

>
> If we are going to have the consistency you want, the way would be to
> downgrade the trunk sections to primary, because after all it's US 2,
> not "Trunk 2".  In the UK, it would be the A2, and unquestionably
> primary.


yes, that's what I want.


Perhaps you should make your own render, and
> submit change proposals to the standard style.  A possibility might be
> coloring roads by ref and hence legal designation, not highway tag, and
> then to draw their width/weight based on physical characteristics.  If
> that's useful, and I think it might be, maybe people will adopt it.


I already got this idea, but I won't rely on the ref and the legal
designation (it may be well done in the UK and in the US, it is not the
case in France), I need a local user-defined value for the importance of an
road : the key "highway" as used in Japan or UK, with trunk as
super-primary, or a new key "importance" which almost duplicates the
highway value (trunk or super_primary, primary, secondary, tertiary,
quaternary, local)
Maybe I should make a test map and come back later :)


djakk

2017-08-24 2:09 GMT+02:00 Greg Troxel <g...@lexort.com>:

>
> djakk djakk <djakk.dj...@gmail.com> writes:
>
> > The thing is, I'm annoyed when there is a primary in the middle of a
> trunk
> > road (example : https://www.openstreetmap.org/#map=12/44.3996/-70.9439)
>
> I haven't been there, but the notion that the road is fundamentally
> different in the primary section is totally sensible and likely to be
> true.
>
> > whereas in the U.K. this does not exist ... tagging rules should be as
> > generic as possible, should not they ?
>
> In an alternate universe, where tags were developed from the ground up
> by committee and vetted against each country's reality, before any
> mapping was done, perhaps.  But that's not what OSM is, for better or
> for worse.  There was a scheme that really made sense in the UK, and
> it's been adapted.
>
> In the US (are you in the US?), there isn't any formal notion of trunk.
> There are US highways, which were agreed long ago to map to primary, and
> there are Interstates, which were agreed to map to motorway.  This
> mapping is arguably sensible.
>
> My impreession is that in the UK, there were A/B/C/U, and then later M
> were created, and I'm not sure when trunk happened.
>
> In the US there were US and state highways, and then later I-.   We
> don't have a naming system for trunk.   So therefore, we have adapted
> high-grade physical to mean a better type of primary.  And basically
> almost everybody is OK with this.
>
> If we are going to have the consistency you want, the way would be to
> downgrade the trunk sections to primary, because after all it's US 2,
> not "Trunk 2".  In the UK, it would be the A2, and unquestionably
> primary.
>
> The real problem is not that trunk means what it does.  It's that
> renderers and perhaps routers focus on the main highway tag, and make
> results you don't like.  Perhaps you should make your own render, and
> submit change proposals to the standard style.  A possibility might be
> coloring roads by ref and hence legal designation, not highway tag, and
> then to draw their width/weight based on physical characteristics.  If
> that's useful, and I think it might be, maybe people will adopt it.
>
> But changing the definition of trunk because you don't like the
> rendering output is even worse than tagging for the renderer - it's
> meta-tagging for the renderer :-)
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[djakk djakk]

Well, it is technically possible, but I was thinking about performance and
stylesheet-maintenance issues ;)


Le dim. 20 août 2017 à 12:49, ajt1...@gmail.com <ajt1...@gmail.com> a
écrit :

> On 20/08/2017 11:36, djakk djakk wrote:
> >
> > Why I want to do that ? To improve openstreetmap, this is a worldwide
> > map and the renderer can't be adapted by countries.
> >
>
> Sure it can - it's perfectly possible for a render to use a
> location-sensitive rendering (I've just done it myself).
>
> Best Regards,
>
> Andy
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[djakk djakk]

I'm pretty sure that the use of "trunk" in UK or in Japan is about the
importance of the road, not about its characteristics :
https://www.mapillary.com/map/im/vBqrj5uGYBw05cd57g9TAg (this is the trunk
road linked in my previous mail ; there is pavement on the right side)

Why I want to do that ? To improve openstreetmap, this is a worldwide map
and the renderer can't be adapted by countries.


Le dim. 20 août 2017 à 11:45, Marc Gemis  a écrit :

> > So basically: please don't go adjusting roads in the US away from
> > established rough consensus because you think it ought to be different.
>
> or anywhere else I would say :-)
>
I'll adjust the wiki first >:>  ^-^
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[djakk djakk]

>
> So basically: please don't go adjusting roads in the US away from
> established rough consensus because you think it ought to be different.


Of course ;-)


Le dim. 20 août 2017 à 04:00, Greg Troxel <g...@lexort.com> a écrit :

>
> djakk djakk <djakk.dj...@gmail.com> writes:
>
> > In England and Japan, trunk roads continue inside village boundaries.
> > https://www.openstreetmap.org/#map=16/52.2685/0.7700 ;
> > https://www.openstreetmap.org/#map=16/35.6261/139.1128
> > Trunk is used as a super-primary class of roads.
>
> Yes, but in the US, that's not what it means.  Trunk differs from
> primary mostly in physical characteristics.
>
> I don't really understand the UK/JP rules.
>
> > I think it is better to try to harmonize between countries, and to use
> the
> > English model all over the world than the one with the motor road sign.
> The
> > latter model can still exist thanks to motorroad=yes.
>
> We don't use the motorroad sign in the US.
>
> So basically: please don't go adjusting roads in the US away from
> established rough consensus because you think it ought to be different.
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[djakk djakk]

In addition of the « traffic » tag, there could be the « importance » tag
(already use for railways - regional or national), with 5 values :
neighbourhood, city, regional, national, continental.

The example of the trunk road around Island : traffic=low,
importance=national :)

djakk


Le sam. 24 févr. 2018 à 14:22, djakk djakk <djakk.dj...@gmail.com> a écrit :

> Yes, we should be able to tag secondary motorway or secondary motorroads. (
> https://www.openstreetmap.org/#map=15/48.8719/2.4496 - https
> ://www.openstreetmap.org/#map=17/48.57211/-2.82279)
>
> djakk
>
>>
>>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[djakk djakk]

Yes, but this rendering does not change when a road crosses a border ^^

djakk


Le sam. 24 févr. 2018 à 05:43, JB  a écrit :

> There is something I don't get.
> Draw primary the same color as trunk and you have no more «
> discontinuity »?
> In France, some commercial map (the most sold, I think) use a different
> rendering for trunk and primary, because you drive faster on trunks. I
> like it, I think they like it, because they have been using this
> rendering for decades.
> JB.
>
> Le 24/02/2018 à 04:45, Fernando Trebien a écrit :
> > As an exercise (and I'm curious about your thoughts on this), I found
> > the main routes between place=city within Czechia (didn't have time to
> > include cities in adjacent countries, bear that in mind).
> >
> > Here's the result [1] using the old colour scheme (motorway=blue,
> > trunk=green, primary=red; with a little mistake: secondary=yellow).
> > Top image uses the current classifications, and bottom image is the
> > result if city-city routes are classified as trunks. Looks very
> > similar to most other maps. Just by looking at it, it's quite obvious
> > which is the main route between each pair of cities. As expected, the
> > method also found out the best ways through and around Praha when
> > going across it. This could also be slightly improved - for example,
> > with little extra time, it is easier to recommend going through route
> > 6 and then Karlovarská than through route 5 and Bucharova.
> >
> > I've checked the three small secondary segments using Street View.
> > Their physical structure is quite good. If still considered
> > undersirable, there are alternative main ways that increase the total
> > time of travel very slightly. Not all routers agreed on taking them
> > anyway.
> >
> > [1] https://i.imgur.com/qFGSveX.jpg
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[djakk djakk]

There is 2 « independant » things in the debate :
1) trunk definition - what is a trunk, a motorway-like road - based on
physical characteristics- or a super-primary road - based on the importance
?
2) wordwilde trunk definition ? - should we have the same definition all
over the world of what is highway= trunk ? (value that are
country-dependant are not that common, aren’t they ?)

djakk


Le sam. 24 févr. 2018 à 10:07, Matej Lieskovský <lieskovsky.ma...@gmail.com>
a écrit :

> 1) If you want to look at a professional map of Czechia, I'd recommend
> www.mapy.cz over google maps as that is the most used and far more
> detailed map.
> 2) I agree that the discontinuities are ugly, but they reflect the state
> on the ground. That section around Sulec is a trunk instead of a primary
> due to the fact that it is a section of future motorway built to motorway
> standard. While your system heavily preferences "importance" of roads, our
> local system reflects reality. Declaring the entire road from Pilsen to
> České Budějovice as trunk due to its importance loses the information that
> there is a section that was built as a motorway link to Písek. I can
> already tell that the road is important because it links Pilsen and České
> Budějovice (by looking at the map), but I also want to know that it was
> built as a primary road and not as a trunk - that means that I'm going to
> expect more single-level junctions and only two lanes for most of the way.
>
> I agree, our trunk roads are a little fuzzy on their definition, but
> elevating random primary roads to trunk is a loss of data for us. Touching
> anything else than reclassifying primary to trunk et vice versa will
> certainly be considered as vandalism in Czechia.
>
> You are demonstrating that you can guess the road class from other data. I
> think it's cute, but does not match on-the-ground data in countries where
> road classification is well-defined.
>
> Look, I've spent a lot of time on this and I have better things to do.
> Fill in the info for your regions on the wiki and then we can see what we
> can do. Until then, bear in mind that "harmonising" European roads will
> likely get you banned. I don't want to sound like I'm threatening you, but
> I've probably spent all the time I'm willing to spend on arguing with some
> random person who wants to break our local road classification system
> "because it will look nicer".
>
> On 24 February 2018 at 07:59, djakk djakk <djakk.dj...@gmail.com> wrote:
>
>> Yes, but this rendering does not change when a road crosses a border ^^
>>
>> djakk
>>
>>
>> Le sam. 24 févr. 2018 à 05:43, JB <jb...@mailoo.org> a écrit :
>>
>>> There is something I don't get.
>>> Draw primary the same color as trunk and you have no more «
>>> discontinuity »?
>>> In France, some commercial map (the most sold, I think) use a different
>>> rendering for trunk and primary, because you drive faster on trunks. I
>>> like it, I think they like it, because they have been using this
>>> rendering for decades.
>>> JB.
>>>
>>> Le 24/02/2018 à 04:45, Fernando Trebien a écrit :
>>> > As an exercise (and I'm curious about your thoughts on this), I found
>>> > the main routes between place=city within Czechia (didn't have time to
>>> > include cities in adjacent countries, bear that in mind).
>>> >
>>> > Here's the result [1] using the old colour scheme (motorway=blue,
>>> > trunk=green, primary=red; with a little mistake: secondary=yellow).
>>> > Top image uses the current classifications, and bottom image is the
>>> > result if city-city routes are classified as trunks. Looks very
>>> > similar to most other maps. Just by looking at it, it's quite obvious
>>> > which is the main route between each pair of cities. As expected, the
>>> > method also found out the best ways through and around Praha when
>>> > going across it. This could also be slightly improved - for example,
>>> > with little extra time, it is easier to recommend going through route
>>> > 6 and then Karlovarská than through route 5 and Bucharova.
>>> >
>>> > I've checked the three small secondary segments using Street View.
>>> > Their physical structure is quite good. If still considered
>>> > undersirable, there are alternative main ways that increase the total
>>> > time of travel very slightly. Not all routers agreed on taking them
>>> > anyway.
>>> >
>>> > [1] https://i.imgur.com/qFGSveX.jpg
>>> >
>>> >

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

[djakk djakk]

Matej, you don’t have to answer quickly, you can answer one time per week
if you prefer, the strong arguments will still weight well :)

djakk


Le sam. 24 févr. 2018 à 10:30, djakk djakk <djakk.dj...@gmail.com> a écrit :

> There is 2 « independant » things in the debate :
> 1) trunk definition - what is a trunk, a motorway-like road - based on
> physical characteristics- or a super-primary road - based on the importance
> ?
> 2) wordwilde trunk definition ? - should we have the same definition all
> over the world of what is highway= trunk ? (value that are
> country-dependant are not that common, aren’t they ?)
>
> djakk
>
>
> Le sam. 24 févr. 2018 à 10:07, Matej Lieskovský <
> lieskovsky.ma...@gmail.com> a écrit :
>
>> 1) If you want to look at a professional map of Czechia, I'd recommend
>> www.mapy.cz over google maps as that is the most used and far more
>> detailed map.
>> 2) I agree that the discontinuities are ugly, but they reflect the state
>> on the ground. That section around Sulec is a trunk instead of a primary
>> due to the fact that it is a section of future motorway built to motorway
>> standard. While your system heavily preferences "importance" of roads, our
>> local system reflects reality. Declaring the entire road from Pilsen to
>> České Budějovice as trunk due to its importance loses the information that
>> there is a section that was built as a motorway link to Písek. I can
>> already tell that the road is important because it links Pilsen and České
>> Budějovice (by looking at the map), but I also want to know that it was
>> built as a primary road and not as a trunk - that means that I'm going to
>> expect more single-level junctions and only two lanes for most of the way.
>>
>> I agree, our trunk roads are a little fuzzy on their definition, but
>> elevating random primary roads to trunk is a loss of data for us. Touching
>> anything else than reclassifying primary to trunk et vice versa will
>> certainly be considered as vandalism in Czechia.
>>
>> You are demonstrating that you can guess the road class from other data.
>> I think it's cute, but does not match on-the-ground data in countries where
>> road classification is well-defined.
>>
>> Look, I've spent a lot of time on this and I have better things to do.
>> Fill in the info for your regions on the wiki and then we can see what we
>> can do. Until then, bear in mind that "harmonising" European roads will
>> likely get you banned. I don't want to sound like I'm threatening you, but
>> I've probably spent all the time I'm willing to spend on arguing with some
>> random person who wants to break our local road classification system
>> "because it will look nicer".
>>
>> On 24 February 2018 at 07:59, djakk djakk <djakk.dj...@gmail.com> wrote:
>>
>>> Yes, but this rendering does not change when a road crosses a border ^^
>>>
>>> djakk
>>>
>>>
>>> Le sam. 24 févr. 2018 à 05:43, JB <jb...@mailoo.org> a écrit :
>>>
>>>> There is something I don't get.
>>>> Draw primary the same color as trunk and you have no more «
>>>> discontinuity »?
>>>> In France, some commercial map (the most sold, I think) use a different
>>>> rendering for trunk and primary, because you drive faster on trunks. I
>>>> like it, I think they like it, because they have been using this
>>>> rendering for decades.
>>>> JB.
>>>>
>>>> Le 24/02/2018 à 04:45, Fernando Trebien a écrit :
>>>> > As an exercise (and I'm curious about your thoughts on this), I found
>>>> > the main routes between place=city within Czechia (didn't have time to
>>>> > include cities in adjacent countries, bear that in mind).
>>>> >
>>>> > Here's the result [1] using the old colour scheme (motorway=blue,
>>>> > trunk=green, primary=red; with a little mistake: secondary=yellow).
>>>> > Top image uses the current classifications, and bottom image is the
>>>> > result if city-city routes are classified as trunks. Looks very
>>>> > similar to most other maps. Just by looking at it, it's quite obvious
>>>> > which is the main route between each pair of cities. As expected, the
>>>> > method also found out the best ways through and around Praha when
>>>> > going across it. This could also be slightly improved - for example,
>>>> > with little extra time, it is easier to recommend going through route
>>>> &

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

[djakk djakk]

Yes, we should be able to tag secondary motorway or secondary motorroads. (
https://www.openstreetmap.org/#map=15/48.8719/2.4496 -
https://www.openstreetmap.org/#map=17/48.57211/-2.82279)

djakk



Le sam. 24 févr. 2018 à 13:34, Fernando Trebien <fernando.treb...@gmail.com>
a écrit :

> On Sat, Feb 24, 2018 at 7:16 AM, Matej Lieskovský
> <lieskovsky.ma...@gmail.com> wrote:
> > One last observation:
> > Austria, Czech Republic, Denmark, Germany, Netherlands, Poland and
> Slovakia
> > all use a similar system where highway=trunk is "motorway-like", with
> trunk
> > either implying motorroad status, or being a prerequisite for it.
>
> In Brazil, the highways that would most closely correspond to the idea
> of a motorroad are actually considered inferior because they lack
> shoulders and are, thus, less safe for travel. They are usually built
> like that to cut costs, not as an ultimately desirable design, so they
> tend to be minor, not major routes.
>
> TagInfo [1] also tells me that there are many motorroads in OSM that
> are primary, not trunk. Probably not in the countries you mentioned,
> but they seem to exist in the UK and in Norway (where there may even
> be some motorroads classified as secondary) [2].
>
> [1] https://taginfo.openstreetmap.org/tags/motorroad=yes#combinations
> [2] https://wiki.openstreetmap.org/wiki/Key:motorroad
>
> > On 24 February 2018 at 11:08, Matej Lieskovský <
> lieskovsky.ma...@gmail.com>
> > wrote:
> >>
> >> 1)
> >> Trunk in Czechia is "motorway-like".
> >> Feel free to document local conventions here:
> >> https://wiki.openstreetmap.org/wiki/Highway_classes
> >> Also, see this:
> >>
> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrunk#International_equivalence
> >>
> >> 2)
> >> Highway classification is not really a measurable thing. I'd compare it
> to
> >> how admin_level works. There is some equivalence, but everyone
> understands
> >> that admin_level=4 means something slightly different in Czechia and in
> the
> >> US.
> >>
> >> I'd be very careful about global definitions as we might easily end up
> >> with entire countries without even a highway=primary. I mean, how can
> Brazil
> >> have unpaved trunk roads? Does Iceland get to keep its trunk road when
> it
> >> has only one city of more than 35000 inhabitants? Do we get to keep
> trunk
> >> roads when there are several cities in China with more people than the
> >> entire Czech Republic? By similar logic the outer border of Czech
> Republic
> >> should be approximately admin_level=4 (to match US states) and trust me
> that
> >> EU integration is not yet at the point where that would be acceptable.
> :)
> >>
> >> Let's get the wiki filled in, we might be wiser afterwards.
> >>
> >> @djakk: Thanks for making the discussion a little more organized.
> >>
> >> On 24 February 2018 at 10:30, djakk djakk <djakk.dj...@gmail.com>
> wrote:
> >>>
> >>> There is 2 « independant » things in the debate :
> >>> 1) trunk definition - what is a trunk, a motorway-like road - based on
> >>> physical characteristics- or a super-primary road - based on the
> importance
> >>> ?
> >>> 2) wordwilde trunk definition ? - should we have the same definition
> all
> >>> over the world of what is highway= trunk ? (value that are
> country-dependant
> >>> are not that common, aren’t they ?)
> >>>
> >>> djakk
> >>>
> >>>
> >>> Le sam. 24 févr. 2018 à 10:07, Matej Lieskovský
> >>> <lieskovsky.ma...@gmail.com> a écrit :
> >>>>
> >>>> 1) If you want to look at a professional map of Czechia, I'd recommend
> >>>> www.mapy.cz over google maps as that is the most used and far more
> detailed
> >>>> map.
> >>>> 2) I agree that the discontinuities are ugly, but they reflect the
> state
> >>>> on the ground. That section around Sulec is a trunk instead of a
> primary due
> >>>> to the fact that it is a section of future motorway built to motorway
> >>>> standard. While your system heavily preferences "importance" of
> roads, our
> >>>> local system reflects reality. Declaring the entire road from Pilsen
> to
> >>>> České Budějovice as trunk due to its importance loses the information
> that
> >>>> there is a section that was built as a motorway link to Písek. 

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

[djakk djakk]

I know that « trunk »  is country-dependent but why not moving it to a
worldwide definition ? Administrative classification could be moved to
other tags :)


djakk

Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský <lieskovsky.ma...@gmail.com>
a écrit :

> Greetings
> I'd like to caution against using this system globally. In Czechia, roads
> are formally classified into classes, which influence signage, ref numbers
> and so on. Deploying this system here would make the tag confusing/useless
> and would likely face enormous backlash. I have no problems with using this
> system in countries without a clearly defined road classification, but
> please don't touch the countries where there is no doubt about what class
> any given road is.
> Happy mapping!
>
> On 22 February 2018 at 16:20, djakk djakk <djakk.dj...@gmail.com> wrote:
>
>> Hello,
>>
>> I totally agree with you, the definition you provide,
>> administrative-free, tends to the same osm map between countries.
>>
>> djakk
>>
>> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien <
>> fernando.treb...@gmail.com> a écrit :
>>
>>> 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 using different classification
>>> criteria)
>>> - account for road network topology
>>> - work in countries with mostly precarious/unpaved roads or
>>> without/unknown official highway classes
>>> - work between settlements as well as within settlements
>>>
>>> Borderline cases are probably inescapable in any system that does not
>>> use solely criteria that are directly verifiable - from the ground, or
>>> from the law. Maybe, in certain developed countries, the system is so
>>> well organized that merely checking signs/laws is sufficient. That
>>> does not mean it is like that everywhere on the planet.
>>>
>>> OSM has so far received a lot of input from communities in developed
>>> countries (mostly Europe, North America and Australia) and hasn't
>>> given much attention to less developed/organized countries. What comes
>>> closest to this is what the HOT Team does, but the judgment of road
>>> classification one can do from satellite images in a foreign country
>>> is much more limited than the criteria that have been raised in this
>>> thread so far.
>>>
>>> I wouldn't endorse tags such as maxspeed:practical due to lack of
>>> verifiability (it should be obvious that different types of vehicles
>>> would achieve different practical speeds). It is better to use the
>>> legal speed in maxspeed=* and describe the practical reason for a
>>> lower speed using surface=*, smoothness=*, and, who knows, maybe the
>>>

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

[djakk djakk]

Don’t worry, when the official system is good, lik in Czechia, it matches
Fernando’s suggestion :)

djakk


Le ven. 23 févr. 2018 à 18:32, Matej Lieskovský <lieskovsky.ma...@gmail.com>
a écrit :

> Don't get me wrong, this system might work well for countries without an
> official system, but what do you expect to happen in the EU?
> Will we have "highway=primary" + "class=tertiary" because some random road
> happens to be a shortcut? Or do you expect us in Czechia to use "class=II"
> while germans use "class=S" so that it actually matches the signage? Will
> the renderer parse ref numbers (and ignore the main tag) or will we receive
> hundreds of complaints about some section of the road having (what every
> local resident will consider to be) the wrong class?
>
> How do you determine "important cities" when even the line between towns
> and cities is country-dependant? Or is using administrative differences
> only not OK for roads?
>
> Even Waze actually follows local administration.
>
>
> Long story short: I am strongly against deploying this system in countries
> with a functioning official classification system.
>
> On 23 February 2018 at 18:06, Fernando Trebien <fernando.treb...@gmail.com
> > wrote:
>
>> +1
>>
>> Administrative classification is not strictly related everywhere to
>> signage, structure and access rights.
>>
>> On Fri, Feb 23, 2018 at 1:12 PM, djakk djakk <djakk.dj...@gmail.com>
>> wrote:
>> > I know that « trunk »  is country-dependent but why not moving it to a
>> > worldwide definition ? Administrative classification could be moved to
>> other
>> > tags :)
>> >
>> >
>> > djakk
>> >
>> > Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský <
>> lieskovsky.ma...@gmail.com>
>> > a écrit :
>> >>
>> >> Greetings
>> >> I'd like to caution against using this system globally. In Czechia,
>> roads
>> >> are formally classified into classes, which influence signage, ref
>> numbers
>> >> and so on. Deploying this system here would make the tag
>> confusing/useless
>> >> and would likely face enormous backlash. I have no problems with using
>> this
>> >> system in countries without a clearly defined road classification, but
>> >> please don't touch the countries where there is no doubt about what
>> class
>> >> any given road is.
>> >> Happy mapping!
>> >>
>> >> On 22 February 2018 at 16:20, djakk djakk <djakk.dj...@gmail.com>
>> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> I totally agree with you, the definition you provide,
>> >>> administrative-free, tends to the same osm map between countries.
>> >>>
>> >>> djakk
>> >>>
>> >>> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien
>> >>> <fernando.treb...@gmail.com> a écrit :
>> >>>>
>> >>>> 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
>> >>>&g

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

[djakk djakk]

We could start with Brasil, France, UK, and Czechia.
But in France and in Brasil the trunk definition is not set yet ...


I've started to use a new tag in Brittany : traffic ;
low-intermediate-heavy-trunk, to show the amount of vehicles per day.
Probably that in combination of other tags (lanes, surface, width) it could
replace the highway tag.

It is probably easier to make new tags than changing old tags :)


djakk

Le ven. 23 févr. 2018 à 20:44, Matej Lieskovský <lieskovsky.ma...@gmail.com>
a écrit :

> Could we perhaps start a wiki page to collect information on how every
> country classifies roads? Something like
> https://wiki.openstreetmap.org/wiki/Highway:International_equivalence but
> intended for the global community instead of the local mappers? More detail
> and less non-english text.
>
> On 23 February 2018 at 20:11, Fernando Trebien <fernando.treb...@gmail.com
> > wrote:
>
>> I'm glad it is not so much of a problem in Czechia and I hope it would
>
> rarely be a problem anywhere.
>>
>> In any case, the idea can be developed further. Matej raises some
>> interesting points that can account for better classification. For
>> example, we could add some bias towards regional and/or national
>> routes, in order to avoid shortcuts (though not forbid them completely
>> if they are significant); likewise, we could add some bias to
>> infrastructure, such as pavement quality, signage quality, feasibility
>> for large vehicles (such as trucks), etc.
>>
>> Most interesting I think is to share with the global community how the
>> local community understands classification. Are access rights really
>> important to the map user, or is it only important to mappers? If so,
>> why can't the renderer parse access tags to decide how to represent
>> the way? (I believe that was the intention when motorroad=* was
>> proposed.)
>>
>> On Fri, Feb 23, 2018 at 3:29 PM, djakk djakk <djakk.dj...@gmail.com>
>> wrote:
>> > Don’t worry, when the official system is good, lik in Czechia, it
>> matches
>> > Fernando’s suggestion :)
>> >
>> > djakk
>> >
>> >
>> > Le ven. 23 févr. 2018 à 18:32, Matej Lieskovský <
>> lieskovsky.ma...@gmail.com>
>> > a écrit :
>> >>
>> >> Don't get me wrong, this system might work well for countries without
>> an
>> >> official system, but what do you expect to happen in the EU?
>> >> Will we have "highway=primary" + "class=tertiary" because some random
>> road
>> >> happens to be a shortcut? Or do you expect us in Czechia to use
>> "class=II"
>> >> while germans use "class=S" so that it actually matches the signage?
>> Will
>> >> the renderer parse ref numbers (and ignore the main tag) or will we
>> receive
>> >> hundreds of complaints about some section of the road having (what
>> every
>> >> local resident will consider to be) the wrong class?
>> >>
>> >> How do you determine "important cities" when even the line between
>> towns
>> >> and cities is country-dependant? Or is using administrative
>> differences only
>> >> not OK for roads?
>> >>
>> >> Even Waze actually follows local administration.
>> >>
>> >>
>> >> Long story short: I am strongly against deploying this system in
>> countries
>> >> with a functioning official classification system.
>> >>
>> >> On 23 February 2018 at 18:06, Fernando Trebien
>> >> <fernando.treb...@gmail.com> wrote:
>> >>>
>> >>> +1
>> >>>
>> >>> Administrative classification is not strictly related everywhere to
>> >>> signage, structure and access rights.
>> >>>
>> >>> On Fri, Feb 23, 2018 at 1:12 PM, djakk djakk <djakk.dj...@gmail.com>
>> >>> wrote:
>> >>> > I know that « trunk »  is country-dependent but why not moving it
>> to a
>> >>> > worldwide definition ? Administrative classification could be moved
>> to
>> >>> > other
>> >>> > tags :)
>> >>> >
>> >>> >
>> >>> > djakk
>> >>> >
>> >>> > Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský
>> >>> > <lieskovsky.ma...@gmail.com>
>> >>> > a écrit :
>> >>> >>
>> >>> >> Greetings
>> >>> >> I

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

[djakk djakk]

I would tag the amount of traffic (official count or estimation) + the
width of the lanes (bidirectional with no hard shoulder ?) + an
appropriated renderer to show heavy traffic + narrow road with a thin red
stroke.


Le ven. 23 févr. 2018 à 21:28, Mark Wagner  a écrit :

> On Thu, 15 Feb 2018 16:14:42 -0200
> Fernando Trebien  wrote:
>
> > 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
>
> "Best" and "large/important" are both rather subjective.  Further, this
> proposed system gives rather questionable results at times.
>
> For example, the fastest route between the cities of Fargo (largest city
> in North Dakota, population 120,000) and Rapid City (second-largest
> city in South Dakota, population 68,000) follows I-29 and I-90, while
> the shortest follows I-94 for a ways, then cuts cross-country on a mix
> of minor state highways to save 70 miles while taking about five minutes
> longer (on a total trip time of 470 minutes).
>
> Which one is the "best"?  If it's the fast route, there's no issue:
> both roads are already "highway=motorway".
>
> If it's the short route, how should it be classified?  Fargo and Rapid
> City are both larger than any city within 200 miles, which would
> seem to make them "large/important", but even by western American
> standards, they're pretty small in an absolute sense.  Trunk, primary,
> or secondary?
>
> --
> Mark
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[djakk djakk]

Hello,

I totally agree with you, the definition you provide, administrative-free,
tends to the same osm map between countries.

djakk

Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien 
a écrit :

> 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 using different classification
> criteria)
> - account for road network topology
> - work in countries with mostly precarious/unpaved roads or
> without/unknown official highway classes
> - work between settlements as well as within settlements
>
> Borderline cases are probably inescapable in any system that does not
> use solely criteria that are directly verifiable - from the ground, or
> from the law. Maybe, in certain developed countries, the system is so
> well organized that merely checking signs/laws is sufficient. That
> does not mean it is like that everywhere on the planet.
>
> OSM has so far received a lot of input from communities in developed
> countries (mostly Europe, North America and Australia) and hasn't
> given much attention to less developed/organized countries. What comes
> closest to this is what the HOT Team does, but the judgment of road
> classification one can do from satellite images in a foreign country
> is much more limited than the criteria that have been raised in this
> thread so far.
>
> I wouldn't endorse tags such as maxspeed:practical due to lack of
> verifiability (it should be obvious that different types of vehicles
> would achieve different practical speeds). It is better to use the
> legal speed in maxspeed=* and describe the practical reason for a
> lower speed using surface=*, smoothness=*, and, who knows, maybe the
> not yet approved hazard=* [5] (though that is intended for signed
> hazards, not subjective/opinionated hazards).
>
> For the sake of long-term sanity, I also wouldn't mix the purpose of
> one tag with the purpose of other tags. To describe the surface, there
> is surface=*, smoothness=* and tracktype=*. To describe access rights,
> there is access=*, foot=*, bicycle=*, motor_vehicle=*, etc. To
> describe legal speed, maxspeed=*. To describe curves, there's
> geometry.
>
> Purpose, perhaps, is the main issue. What is the purpose of highway
> classification? Is it to save us the work of adding extra tags? Is it
> to allow the renderer to produce a cleaner output at low zoom levels?
> Is it to allow routers to assume default speeds? Maybe to guide their
> routing heuristics? Is it to express some sort of importance? If so,
> by which perspective - urbanistic, traffic engineering, movement,
> commercial value, cultural/fame, historic, some combination of those?
> Should the purpose be the same in every country?
>
> It may be interesting to also discuss the classification adopted by
> other maps. I don't have a reference for Google (originally TeleAtlas)
> or Here.com (originally Navteq), but Waze publishes its per-country
> road classification criteria in its wiki. [6-16]
>
> [1]
> https://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dtrunk#change_.22high_performance.22_to_.22high_importance.22
> [2] https://wiki.openstreetmap.org/wiki/Verifiability#Problematic_tags
> [3]
> https://wiki.openstreetmap.org/wiki/User:Ftrebien/Drafts/Generic_highway_classification_principles#Schematic_diagram_and_general_comments
> [4] 

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

[djakk djakk]

No, all highways are areas :) Mapping them as a line is a manual
generalization ;)


djakk


Le ven. 10 août 2018 à 12:15, Andy Townsend  a écrit :

>
> > So basing on your opinions, it looks like highway=* + area=yes isn't
> incorrect, it's just not documented.
>
> I'd suggest that it depends what you're mapping. If it's a predominantly
> linear feature then it would be wrong to try and "somehow record the width"
> using area=yes on the highway tag - use area:highway (or width) for that.
>
> If it really is an area, then area=yes would make sense.  Most highways
> are not, though.
>
> Best Regards,
> Andy
>
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

[djakk djakk]

I don’t get why highway=footway + area=yes is considered as wrong tagging !


djakk



Le mer. 8 août 2018 à 12:52, Tomasz Wójcik  a écrit :

> As highway=footway etc. tags are set to "should not be used on areas" on
> Wiki, and mapping them in combination with area=yes is not documented at
> all and considered as wrong tagging by part of users, there is a key
> "area:highway=*" (133k uses at the moment). Part of users still map footway
> areas as a combination anyway, propably because it's rendered by default
> style. Due to our rules, that we shouldn't have 2 active tagging schemes
> for the same feature, so we should discuss this topic.
>
> I vote for area:highway=* key, because it's simpler, and it gives a
> possibility to show also street areas with crossings in the future.
>
> * Wiki with specyfications of a:h=* for certain keys:
> https://wiki.openstreetmap.org/wiki/Key:area:highway
> * TagInfo: https://taginfo.openstreetmap.org/keys/area:highway
> * area:highway=* visualisation: http://osmapa.pl/w/area
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Plus code grid service

[djakk djakk]

Well, it is possible for a human to memorize it :)

Julien « djakk »


Le lun. 19 nov. 2018 à 17:22, Mateusz Konieczny  a
écrit :

> It is still not clear to me why new way of writing latitude and longitude
> is supposed to be interesting.
>
> 19. Nov 2018 16:43 by drinc...@google.com:
>
> We're really excited to launch a free plus code grid service at
> https://grid.plus.codes
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk-fr] Marché

[djakk djakk]

Salut,

est-ce souhaitable de tagger précisément un marché, stand par stand ? Genre
le marché qui a lieu une fois par semaine sur un parking.


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

Re: [OSM-talk-fr] Jungle Bus a besoin de vous + Ghana

[djakk djakk]

à H-9, plus que 700€ pour atteindre le palier "rendu cartographique" 8-)

Le 11 juillet 2017 à 15:51, Florian LAINEZ  a écrit :

> Salut,
> Jungle Bus, c'est le projet qui vise à cartographier les points d'arrêt et
> les lignes de transport dans OSM.
> Nous voulons créer de nouveaux outils dont la simplicité d'utilisation
> nous permettra de mapper plus efficacement mais aussi d'élargir la
> communauté OSM.
>
> Nous en avons déjà parlé durant le SotM-fr, nous menons une campagne de
> crowdfunding, vous nous aidez à réaliser nos projets ?
> https://fr.ulule.com/jungle-bus/
>
> Voici où l'on en est pour l'instant :
> -terminer le dév de l'appli mobile - DÉJÀ FINANCÉ
> -développer une nouvelle interface graphique pour le plugin PT_assistant
> de JOSM - DÉJÀ FINANCÉ
> -créer un nouveau rendu transport en vectoriel - ON Y EST PRESQUE !
>
> Il reste *jusqu'à jeudi soir minuit *pour nous soutenir, merci à tous
> pour votre aide.
> N'hésitez pas à en parler autour de vous, et si vous avez twitter,
> pourriez-vous svp RT nos annonces ces prochaines jours ?
> https://twitter.com/BusJungle
>
> --
> Dans la lancée de la campagne, nous allons cartographier dans OSM le
> réseau de transport informel de Accra, la capitale du Ghana, avec notre
> partenaire AFD (agence france développement). Je décolle dimanche donc si
> vous avez un message pour la communauté OSM du Ghana, c'est le moment de me
> le transmettre ;)
>
> Jungle !
>
> --
>
> *Florian Lainez*
> @overflorian 
>
> ___
> 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] Bar ou resto des 2 côtés du pâté de maison

[djakk djakk]

Pour la terrasse de l'autre côté de la rue, ça peut aussi concerner les
grosses routes : http://forum.sara-infras.fr/viewtopic.php?p=188224#p188224
 :)

Le principal problème entre Moulins et Vichy est la traversee de St
Pourcain a cause d'un...bar/resto. La terrasse est de l'autre cote
de la rue et c est un aller et retour incessant de chaque cote par les
serveurs. J'y avais bien perdu 15-20 min l'été dernier.


Le 12 juillet 2017 à 21:03, Philippe Verdy  a écrit :

> Autre exemple à côté de chez moi:
> https://www.openstreetmap.org/#map=19/46.32367/-0.45893
>
> Tous les bars/pubs/restaus sur l'esplanade ont des terrasses situés de
> l'autre côté d'une voie réservée aux piétons/cyclistes et au passage des
> véhicules de sécurité (police/pompiers) ou de service (camions poubelle,
> certaines livraisons, transports de fonds) où peuvent aussi circuler
> (vitesse: au pas) des véhicules de transport d'handicapés (minibus ou taxis
> et VSL). Les véhicules autorisés ne sont pas rares (même aux heures
> d'ouverture de ces terrasses jusqu'à 1h du matin, parfois 3h lors de
> certaines fêtes : la police passe souvent, les convoyeurs de fonds aussi,
> les camions de livraison peuvent passer aussi à certaines heures le matin
> alors que les terrasses sont déjà ouvertes pour certains commerçants).
>
> Cette esplanade était il y a quelques années une voie de circulation
> normale.
>
> Le 12 juillet 2017 à 20:44,  a écrit :
>
>> Le 12/07/2017 à 19:18, marc marc - marc_marc_...@hotmail.com a écrit :
>>
>> si c'est 2 bâtiments séparé par une route publique... pour moi c'est 2
>> restaurant même sils ont le même patron.. un peu comme 2 macdo...
>> j'imagine pas une cuisine unique qui désert l'autre côté de la rue :)
>>
>> Comme illustré par Philippe ça dépend de la voirie en question.
>> Typiquement https://www.openstreetmap.org#map=19/43.94451/4.80757
>> La "rue" Place des Corps-Saints n'a pas empêché certain-e-s d'entre nous
>> d'être servis sur la place alors que le bistro se trouvait de l'autre côté.
>> Pour la pizzéria, oui il fallait aller chercher sa pizza mais la terrasse
>> appartenait au bistro, pas à la pizzéria.
>> La bonne métrique est peut-être : est-ce que le numéro pour réserver est
>> le même ? Est-ce que si on entre dans l'un ou l'autre on peut nous placer
>> dans l'autre lieu ?
>> 2 MerDo n'ont pas le même numéro même s'ils ont le même patron.
>> Et d'ailleurs ce n'est pas la même société, histoire de rester en dessous
>> de 50 salarié-e-s par exemple.
>>
>> Jean-Yvon
>>
>> ___
>> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OSM transport] Projet du mois - arrêts de bus

[djakk djakk]

C'est moi ahaha ^^' j'ai pour le moment juste ajouté les arrêts de bus
(avec juste highway = 'stop') dont on voit les zébras sur l'image aérienne
d'IGN, manuellement donc. J'ai comparé les arrêts du GTFS de IdF
Mobilités-ex-STIF (qui ne sont pas toujours bons) avec ceux déjà présents
dans openstreetmap.

Ensuite, je compte faire comme ça :
Pour nommer les arrêts sans nom, je m'aide de ma carte
http://itineraires.idf.free.fr/idf-juillet-2017/?15,1.98987,48.8725 qui
utilise les noms du fichier GTFS de IdF Mobilités-ex-STIF quand il n'y a
pas de nom osm.
Plus+ une requête chez Overpass pour voir où sont ces arrêts sans nom
https://overpass-turbo.eu :

[out:json][timeout:25];
> // gather results
> (
>   // query part for: “highway=primary and traffic!=*”
>   node["highway"="bus_stop"][! "name"]({{bbox}});
> );
> // print results
> out body;
> >;
> out skel qt;


Le 24 juillet 2017 à 23:32, marc marc  a écrit :

> Je trouve étonnant les stats sur les 6 derniers jours :
> Parmi les 500 nouveaux arrêt, 200 ont été ajouté sans nom.
> Quelqu'un a fait un import partiel ?
> J'ai du mal à imaginer quel source permet d'ajouter autant d'arrêt mais
> sans en connaître le nom.. p'tre du mapillary
>
> Allez hop demain j'enfourche le vélo pour aller maper le dernier arrêt
> de bus sans nom qui reste dans les environs pendant que Noémie modifie
> un valeur des marches :-)
>
> Le 24. 07. 17 à 20:27, Noémie Lehuby a écrit :
> > Hello,
> >
> > il ne sous reste plus qu'une semaine de projet du mois sur les arrêts de
> > bus. Et pourtant, tant de choses à faire !
> >
> > Par exemple, saviez-vous qu'il y a encore
> >
> >   * 12 949 arrêts qui n'ont pas de nom
> >   * 136 arrêts avec un tag FIXME
> >
> >
> > https://wiki.openstreetmap.org/wiki/FR:Project_of_the_
> month/arr%C3%AAts_de_bus
> >
> >
> > Go go go !
> >
> > Noémie
> >
> >
> > Le 10/07/2017 à 09:38, Noémie Lehuby a écrit :
> >> Hello,
> >>
> >> Ce n'est pas parce que ce sont les bus sont passés en horaires d'été
> >> qu'il faut mollir les amis, le mois n'est pas encore fini et il y a
> >> encore beaucoup d'arrêts de bus à mettre sur la carte !
> >>
> >> Pas d'excuses : les petits trains touristiques et les navettes pour
> >> aller à l'aéroport sont aussi concernées.
> >>
> >> Ouvrez l'oeil, il en manque plus qu'on ne pourrait le croire ;)
> >>
> >> https://wiki.openstreetmap.org/wiki/FR:Project_of_the_
> month/arr%C3%AAts_de_bus
> >>
> >>
> >
> > --
> > @nlehuby
> ___
> 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] [OSM transport] Projet du mois - arrêts de bus

[djakk djakk]

Oui effectivement j'ai carburé ^^ merci pour le comptage je ne pensais pas
en avoir fait autant :O

Pour le soucis avec l'imagerie aérienne, je met un "source"='BDOrtho IGN'
sur l'arrêt de bus créé ou bien le "source" du changeset suffit ? Ou bien
j'arrête de mapper avec cette technique, laissant le boulot à un mapper
local ?

Le 26 juillet 2017 à 09:42, Florian LAINEZ  a écrit :

> Warning... les images aériennes ne sont pas forcément de toute fraîcheur
>> et les arrêts de bus n'ont pas un emplacement immuable, surtout qu'il y en
>> a pas mal qui font l'objet de travaux pour mise aux normes
>> d'accessibilité... donc warning ;)
>>
>
> +1
>
> Le 25 juillet 2017 à 17:52, Christian Quest  a
> écrit :
>
>> Le 25/07/2017 à 17:29, marc marc a écrit :
>>
>>> djakk 200 arrêts trouvé sur imagerie sat en 6 jours ? woaw tu carbures !
>>>
>>>
>> Warning... les images aériennes ne sont pas forcément de toute fraîcheur
>> et les arrêts de bus n'ont pas un emplacement immuable, surtout qu'il y en
>> a pas mal qui font l'objet de travaux pour mise aux normes
>> d'accessibilité... donc warning ;)
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
>
> *Florian Lainez*
> @overflorian 
>
> ___
> 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] [OSM transport] Projet du mois - arrêts de bus

[djakk djakk]

Oui, il faut une source par tag en fait.

Le 26 juillet 2017 à 17:51, Jean-Claude Repetto  a écrit :

> Le 26/07/2017 à 15:59, Jo a écrit :
> > Il est préférable de taguer les source sur les changeset. Sinon on va
> > arriver à une situation comme en France où chaque objet a un tag source
> > d'un kilomètre de long qui prend énormément de place dans la BDD.
> >
>
> Bonjour,
>
> En général, on utilise simultanément plusieurs sources (imageries
> aériennes, cadastre, terrain, ...). Si on veut être précis, on doit
> indiquer la source pour chaque objet (et même parfois plusieurs sources
> pour un seul objet, par exemple une source pour la position et une autre
> source pour le nom).
>
> Jean-Claude
>
>
> ___
> 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] [OSM transport] Projet du mois - arrêts de bus

[djakk djakk]

Alors quelles sont les statistiques du jour concernant les arrêts sans nom
? O:-)

Le 26 juillet 2017 à 18:59, Pierre-Yves Berrard <
pierre.yves.berr...@gmail.com> a écrit :

> En ce qui me concerne, séparer les changeset selon la source est
> impossible.
> Je travaille le plus souvent sur une zone donnée, en essayant de
> positionner les objets les uns par rapport aux autres, donc en m'appuyant
> pour ce faire sur toutes les sources disponibles.
>
> Question annexe (mais importante) : avec la source uniquement sur le
> changeset, comment retrouver (facilement) la source pour qui exporterait
> les données ?
>
> PY
>
> Le 26 juillet 2017 à 18:30, marc marc  a écrit
> :
>
>> Le 26. 07. 17 à 17:51, Jean-Claude Repetto a écrit :
>> > une source pour la position et une autre source pour le nom
>> oui source:geometry et source:name ont du sens.
>> mais on peux mettre ce niveau de détail dans le changeset non ?
>> tu as un exemple d'un changeset que tu as fait qui aurait un tag précis
>> ayant une valeur différente selon l'objet sans que cela justifie de se
>> faciliter la vie avec 2 changeset ?
>>
>> ce qui n'a pas de sens c'est source=machin sur l'objet puisque la seule
>> façon de savoir ce que cela concerne c'est de retrouver le changeset
>> ___
>> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Soirée Jungle Bus mardi 25 juillet à Paris

[djakk djakk]

(retour de nuit après la soirée où je consommerai avec beaucoup de
modération bien sûr ;))

Le 22 juillet 2017 à 15:21, djakk djakk <djakk.dj...@gmail.com> a écrit :

> Je viens ! Si il y a des gens de Bretagne qui veulent y aller, je propose
> un covoiturage Rennes <-> Paris !
>
> Le 22 juillet 2017 à 12:55, Florian LAINEZ <winner...@free.fr> a écrit :
>
>> Hello,
>> L'équipe de Jungle Bus vous propose de se retrouver autour d'une bonne
>> [OpenBeerMap=yes] mardi prochain pour célébrer la fin de campagne de
>> crowdfunding.
>> Tous les détails sont sur la page https://fr.ulule.com/jungle-bu
>> s/news/soiree-de-fin-de-campagne-25-juillet-a-paris-147593/
>>
>> Faites passer le message !
>>
>> On se retrouve là-bas ? :)
>>
>> --
>>
>> *Florian Lainez*
>> @overflorian <http://twitter.com/overflorian>
>>
>> ___
>> 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] Soirée Jungle Bus mardi 25 juillet à Paris

[djakk djakk]

Je viens ! Si il y a des gens de Bretagne qui veulent y aller, je propose
un covoiturage Rennes <-> Paris !

Le 22 juillet 2017 à 12:55, Florian LAINEZ  a écrit :

> Hello,
> L'équipe de Jungle Bus vous propose de se retrouver autour d'une bonne
> [OpenBeerMap=yes] mardi prochain pour célébrer la fin de campagne de
> crowdfunding.
> Tous les détails sont sur la page https://fr.ulule.com/jungle-
> bus/news/soiree-de-fin-de-campagne-25-juillet-a-paris-147593/
>
> Faites passer le message !
>
> On se retrouve là-bas ? :)
>
> --
>
> *Florian Lainez*
> @overflorian 
>
> ___
> 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] Meetup Open Transport à Paris 05/07

[djakk djakk]

Je viens ! :)

Le 27 juin 2017 à 15:21, Florian LAINEZ  a écrit :

>
> Le 27 juin 2017 à 12:29, Jo  a écrit :
>
>> Venir à Paris ne sera pas possible pour moi. Y a-t-il moyen de suivre en
>> ligne?
>
>
> Il n'est malheureusement pas prévu de retransmission, désolé.
>
> --
>
> *Florian Lainez*
> @overflorian 
>
> ___
> 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] Communes pratiquant l'extinction de l'éclairage public

[djakk djakk]

Salut,

dans ma commune seules quelques rues sont concernées, du coup il faudrait
tagguer rue par rue, avec la clé "lit=" ; pour la valeur, à voir …

Julien djakk (http://itineraires.de.bus.free.fr)

Le 30 avril 2017 à 10:21, Paul Desgranges  a
écrit :

> Bonjour,
>  Existe-t-il / est-il souhaitable / est-il possible de rajouter un tag sur
> les communes qui pratiquent l'extinction de l'éclairage public
> 
> ?
>  Merci
>
>
> ___
> 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] Trunk

[djakk djakk]

Oui je pense qu'il parlait du panneau "route pour automobiles"
(motorroad=yes ; le panneau carré bleu avec une voiture blanche de face)


djakk

Le ven. 18 août 2017 à 19:47, Axelos <axe...@broman.fr> a écrit :

> Coucou,
>
> Le 18/08/2017 à 14:20, marc marc a écrit :
> > Le 18. 08. 17 à 12:20, djakk djakk a écrit :
> >> Je reviens sur ce sujet épineux qu'est la classification "trunk".
> >> But du jeu = mettre à jour le Wiki qui est contradictoire ;)
> >
> > qu-est ce qui est précisément contradictoire su le wiki ?
> >
> https://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments_cartographiques
> > me semble assez clair, si tu as la panneau "Voie rapide" tu es en trunk.
>
> Sauf qu'il n'existe pas de panneau voie rapide !
>
>
> --
>
> Je cherche à protéger ma vie privée numérique,
> s’il vous plaît faites-le aussi pour moi,
> choisissez une adresse de courriel alternative respectueuse.
>
> ___
> 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] Tagger le marquage routier

[djakk djakk]

Alors non, ça serait surface_marking=shore_and_axial | axial_only |
shore_only | small_axial (small axial pour les marquages en Z)


Le ven. 18 août 2017 à 21:42, Philippe Verdy <verd...@wanadoo.fr> a écrit :

> Tu donc suggères un tag de type "lanes:separator=line|dashes|marks" ou
> "lanes:crossing=forbidden|permissive|indicative" ?
>
> Le 18 août 2017 à 18:42, djakk djakk <djakk.dj...@gmail.com> a écrit :
>
>> "width" est exclusivement en numérique, je préférerai une clé qui
>> permette des valeurs textuelles … dont on pourra éventuellement en déduire
>> une valeur "width" selon les standards en vigueur.
>>
>> Le 18 août 2017 à 16:03, Jo <winfi...@gmail.com> a écrit :
>>
>>> Il y a aussi le tag width
>>>
>>> On Aug 18, 2017 15:42, "marc marc" <marc_marc_...@hotmail.com> wrote:
>>>
>>>> Le 18. 08. 17 à 10:50, djakk djakk a écrit :
>>>> > Je me demande si il ne serait pas intéressant de tagger le marquage
>>>> > routier afin d'estimer la largeur d'une route
>>>> est-ce qu'utiliser "lanes" ne serrait-il pas un bon début ? je me rend
>>>> compte seulement maintenant que highway=residential n'as pas de valeur
>>>> "lanes" par défaut. j'avais mis des lanes=1 ou 3 là oü c'était
>>>> applicable mais pas de lanes=2 pour les autres.
>>>> il y a aussi la valeur controversée 1.5 pour indiquer qu'il est
>>>> nécessaire d’empiéter sur le bas côté pour se croiser
>>>>
>>>> ceci dit, dans le rendu par défaut, lanes=1 ou lanes=3 ont la même
>>>> apparence. avant de rajouter des tag ce serrait peut-être utile de voir
>>>> si c'est possible d'améliorer le rendu des tag existants
>>>> ___
>>>> 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
>>>
>>>
>>
>> ___
>> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tagger le marquage routier

[djakk djakk]

Il existe des routes à 2 voies larges (avec marquage routier à proximité
des accotements) et des routes à 2 voies étroites (sans marquage routier à
proximité des accotements) ; je ne pense pas que lanes=2.5 soit "bon".
Et comme dit Philippe, il y a certains marquages spéciaux en forme de Z
pour les petites routes de campagne à 2 voies très étroites (mais pas aussi
étroites que lanes=1.5 ^^)

Le ven. 18 août 2017 à 15:42, marc marc <marc_marc_...@hotmail.com> a
écrit :

> Le 18. 08. 17 à 10:50, djakk djakk a écrit :
> > Je me demande si il ne serait pas intéressant de tagger le marquage
> > routier afin d'estimer la largeur d'une route
> est-ce qu'utiliser "lanes" ne serrait-il pas un bon début ? je me rend
> compte seulement maintenant que highway=residential n'as pas de valeur
> "lanes" par défaut. j'avais mis des lanes=1 ou 3 là oü c'était
> applicable mais pas de lanes=2 pour les autres.
> il y a aussi la valeur controversée 1.5 pour indiquer qu'il est
> nécessaire d’empiéter sur le bas côté pour se croiser
>
> ceci dit, dans le rendu par défaut, lanes=1 ou lanes=3 ont la même
> apparence. avant de rajouter des tag ce serrait peut-être utile de voir
> si c'est possible d'améliorer le rendu des tag existants
> ___
> 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] Trunk

[djakk djakk]

Alors, le panneau "route pour automobiles" peut s'appliquer sur des routes
à 2 voies sans séparateur central comme la N79 vers Montbeugny ; à
l'inverse, une 2*2 voies avec séparateur central n'est pas forcément une
"route pour automobile" comme la N175 vers Servon dans la Manche.

Sinon, sur la page http://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dtrunk
il est écrit "Dispose en général de 2x2 voies et d'une séparation centrale
(rail de sécurité). "  : le "en général" est-il de trop ?


Le ven. 18 août 2017 à 16:08, marc marc <marc_marc_...@hotmail.com> a
écrit :

> Le 18. 08. 17 à 12:20, djakk djakk a écrit :
> > Je reviens sur ce sujet épineux qu'est la classification "trunk".
> > But du jeu = mettre à jour le Wiki qui est contradictoire ;)
>
> qu-est ce qui est précisément contradictoire su le wiki ?
> https://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments_cartographiques
> me semble assez clair, si tu as la panneau "Voie rapide" tu es en trunk.
> Si tu le perds lors d'une traversée de village, le niveau rétrograde.
> Seul la phrase
> "Voie ayant les caractéristiques d'une autoroute. En général, une 2x2
> voies avec séparation centrale. "
> pourrait s'écrire
> "Voie ayant les caractéristiques d'une autoroute avec une séparation
> centrale entre les voies de sens opposées. En général 2x2 voies"
> ___
> 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] Tagger le marquage routier

[djakk djakk]

"width" est exclusivement en numérique, je préférerai une clé qui permette
des valeurs textuelles … dont on pourra éventuellement en déduire une
valeur "width" selon les standards en vigueur.

Le 18 août 2017 à 16:03, Jo <winfi...@gmail.com> a écrit :

> Il y a aussi le tag width
>
> On Aug 18, 2017 15:42, "marc marc" <marc_marc_...@hotmail.com> wrote:
>
>> Le 18. 08. 17 à 10:50, djakk djakk a écrit :
>> > Je me demande si il ne serait pas intéressant de tagger le marquage
>> > routier afin d'estimer la largeur d'une route
>> est-ce qu'utiliser "lanes" ne serrait-il pas un bon début ? je me rend
>> compte seulement maintenant que highway=residential n'as pas de valeur
>> "lanes" par défaut. j'avais mis des lanes=1 ou 3 là oü c'était
>> applicable mais pas de lanes=2 pour les autres.
>> il y a aussi la valeur controversée 1.5 pour indiquer qu'il est
>> nécessaire d’empiéter sur le bas côté pour se croiser
>>
>> ceci dit, dans le rendu par défaut, lanes=1 ou lanes=3 ont la même
>> apparence. avant de rajouter des tag ce serrait peut-être utile de voir
>> si c'est possible d'améliorer le rendu des tag existants
>> ___
>> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tagger le marquage routier

[djakk djakk]

Exemple de marquage en Z :
https://www.mapillary.com/map/im/JdyGWzh-kFVK1Vc1PTDh_w
Exemple de "axial_only" :
https://www.mapillary.com/map/im/r5rG4Crvps9LVHbY-G9eBw
Un peu plus loin sur la même route, ça s'élargit : "shore_and_axial" :
https://www.mapillary.com/map/im/6inui7q7jGH5TNhZBYafHA
"Shore_only" (typique de la Provence) :
https://www.mapillary.com/map/im/xeSE_1GqqDcKPQMWOR0vtg


Le ven. 18 août 2017 à 22:27, djakk djakk <djakk.dj...@gmail.com> a écrit :

> Alors non, ça serait surface_marking=shore_and_axial | axial_only |
> shore_only | small_axial (small axial pour les marquages en Z)
>
>
> Le ven. 18 août 2017 à 21:42, Philippe Verdy <verd...@wanadoo.fr> a
> écrit :
>
>> Tu donc suggères un tag de type "lanes:separator=line|dashes|marks" ou
>> "lanes:crossing=forbidden|permissive|indicative" ?
>>
>> Le 18 août 2017 à 18:42, djakk djakk <djakk.dj...@gmail.com> a écrit :
>>
>>> "width" est exclusivement en numérique, je préférerai une clé qui
>>> permette des valeurs textuelles … dont on pourra éventuellement en déduire
>>> une valeur "width" selon les standards en vigueur.
>>>
>>> Le 18 août 2017 à 16:03, Jo <winfi...@gmail.com> a écrit :
>>>
>>>> Il y a aussi le tag width
>>>>
>>>> On Aug 18, 2017 15:42, "marc marc" <marc_marc_...@hotmail.com> wrote:
>>>>
>>>>> Le 18. 08. 17 à 10:50, djakk djakk a écrit :
>>>>> > Je me demande si il ne serait pas intéressant de tagger le marquage
>>>>> > routier afin d'estimer la largeur d'une route
>>>>> est-ce qu'utiliser "lanes" ne serrait-il pas un bon début ? je me rend
>>>>> compte seulement maintenant que highway=residential n'as pas de valeur
>>>>> "lanes" par défaut. j'avais mis des lanes=1 ou 3 là oü c'était
>>>>> applicable mais pas de lanes=2 pour les autres.
>>>>> il y a aussi la valeur controversée 1.5 pour indiquer qu'il est
>>>>> nécessaire d’empiéter sur le bas côté pour se croiser
>>>>>
>>>>> ceci dit, dans le rendu par défaut, lanes=1 ou lanes=3 ont la même
>>>>> apparence. avant de rajouter des tag ce serrait peut-être utile de voir
>>>>> si c'est possible d'améliorer le rendu des tag existants
>>>>> ___
>>>>> 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
>>>>
>>>>
>>>
>>> ___
>>> 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
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tagger le marquage routier

[djakk djakk]

Ça n'est pas vraiment un Z c'est clair mais je voulais *résumer* en une
lettre ce marquage ;P


Le sam. 19 août 2017 à 11:45, Philippe Verdy <verd...@wanadoo.fr> a écrit :

> Je ne sais pas où vous voyez des Z, puisqu'il n'y a pas de diagonale, mais
> juste deux traits courts (environ 15 cm chacun pas plus et larges de 10cm
> environ) accolés avec un petit décalage (ils se chevauchent légèrement sur
> la bordure). Ces symboles sont très espacés (tous les 30 à 50 mètres
> environ, parfois moins si la route n'est pas droite ou approche le sommet
> d'une bosse avec une distance de visibilité plus faible) ; ils ressemblent
> à ça et sont tracés rapidement en deux coups de pinceau.
>
>   ██
>   ██
>   ██
>   ██
>   ██
>   ██
>    ██
>    ██
>    ██
>
> Ce marquage est très présent sur les routes de liaison intercommunales
> dans des zones périurbaines.
>
> En milieu rural (routes agricoles ou quelques rares résidences, les
> principaux usagers sont les engins agricoles, les cyclistes et promeneurs à
> pied) il n'y a le plus souvent aucun marquage, c'est une chaussée unique où
> on roule au milieu parce que c'est la meilleure bande de roulement et les
> cotés sont peu ou pas stabilisés (on doit ralentir très fortement pour se
> croiser au pas, en roulant dans les gravillon ou sur la pelouse et dans des
> flaques de boue et sur les morceaux de bitume qui se détachent de la
> bordure, avec un des véhicules qui doit se garer prudemment sur le bas côté
> et redémarrer doucement pour ne pas s'enliser dans la boue ou creuser
> davantage des ornières ou de projeter les cailloux, une seule roue sur la
> chaussée assurant la traction).
>
> Philippe
>
>
> Le 19 août 2017 à 01:49, <osm.sanspourr...@spamgourmet.com> a écrit :
>
>> Pas très cohérent.
>>
>> Vous distinguez le marquage interne ou/et externe. OK
>>
>> Mais dans l'interne vous distinguez le Z/papillon du reste.
>>
>> Par contre vous ne distinguez pas en externe le trait long du trait court.
>>
>> Voir
>> https://fr.wikipedia.org/wiki/Signalisation_routi%C3%A8re_horizontale ou
>> mieux https://en.wikipedia.org/wiki/Road_surface_marking et
>>
>> et sinon pour un tag surface_marking:FR
>>
>>
>> https://fr.wikipedia.org/wiki/Signalisation_routi%C3%A8re_horizontale_en_France
>>
>> Il vaut mieux prendre toutes les voies de gauche à droite dans le sens du
>> way/
>> none|none|none : double sens étroit.
>> dash|continuous|dash : marquage de rives avec une ligne continue.
>>
>> On dit qu'on a un cas de plus que de voies.
>>
>> Je crois qu'il y a déjà des propositions mais je n'ai pas retrouvé.
>> Ou j'ai juste déjà lu le dernier lien.
>>
>> Jean-Yvon
>>
>>
>> Le 18/08/2017 à 23:10, djakk djakk - djakk.dj...@gmail.com a écrit :
>>
>> Exemple de marquage en Z :
>> https://www.mapillary.com/map/im/JdyGWzh-kFVK1Vc1PTDh_w
>> Exemple de "axial_only" :
>> https://www.mapillary.com/map/im/r5rG4Crvps9LVHbY-G9eBw
>> Un peu plus loin sur la même route, ça s'élargit : "shore_and_axial" :
>> https://www.mapillary.com/map/im/6inui7q7jGH5TNhZBYafHA
>> "Shore_only" (typique de la Provence) :
>> https://www.mapillary.com/map/im/xeSE_1GqqDcKPQMWOR0vtg
>>
>>
>> Le ven. 18 août 2017 à 22:27, djakk djakk <djakk.dj...@gmail.com> a
>> écrit :
>>
>>> Alors non, ça serait surface_marking=shore_and_axial | axial_only |
>>> shore_only | small_axial (small axial pour les marquages en Z)
>>>
>>>
>>> Le ven. 18 août 2017 à 21:42, Philippe Verdy <verd...@wanadoo.fr> a
>>> écrit :
>>>
>>>> Tu donc suggères un tag de type "lanes:separator=line|dashes|marks" ou
>>>> "lanes:crossing=forbidden|permissive|indicative" ?
>>>>
>>>> Le 18 août 2017 à 18:42, djakk djakk <djakk.dj...@gmail.com> a écrit :
>>>>
>>>>> "width" est exclusivement en numérique, je préférerai une clé qui
>>>>> permette des valeurs textuelles … dont on pourra éventuellement en déduire
>>>>> une valeur "width" selon les standards en vigueur.
>>>>>
>>>>> Le 18 août 2017 à 16:03, Jo <winfi...@gmail.com> a écrit :
>>>>>
>>>>>> Il y a aussi le tag width
>>>>>>
>>>>>> On Aug 18, 2017 15:42, "marc marc" <marc_marc_...@hotmail.com> wrote:
>>>>>>
>>>>>>> Le 18. 08. 17 à 10:50, djakk djakk a 

Re: [OSM-talk-fr] Tagger le marquage routier

[djakk djakk]

Ça s'appelle un "Module de Roue Étroite" :
https://virages.zendesk.com/hc/fr/articles/200989196-Le-marquage-des-routes-étroites
:)


Le sam. 19 août 2017 à 12:08, djakk djakk <djakk.dj...@gmail.com> a écrit :

> Ça n'est pas vraiment un Z c'est clair mais je voulais *résumer* en une
> lettre ce marquage ;P
>
>
> Le sam. 19 août 2017 à 11:45, Philippe Verdy <verd...@wanadoo.fr> a
> écrit :
>
>> Je ne sais pas où vous voyez des Z, puisqu'il n'y a pas de diagonale,
>> mais juste deux traits courts (environ 15 cm chacun pas plus et larges de
>> 10cm environ) accolés avec un petit décalage (ils se chevauchent légèrement
>> sur la bordure). Ces symboles sont très espacés (tous les 30 à 50 mètres
>> environ, parfois moins si la route n'est pas droite ou approche le sommet
>> d'une bosse avec une distance de visibilité plus faible) ; ils ressemblent
>> à ça et sont tracés rapidement en deux coups de pinceau.
>>
>>   ██
>>   ██
>>   ██
>>   ██
>>   ██
>>   ██
>>    ██
>>    ██
>>    ██
>>
>> Ce marquage est très présent sur les routes de liaison intercommunales
>> dans des zones périurbaines.
>>
>> En milieu rural (routes agricoles ou quelques rares résidences, les
>> principaux usagers sont les engins agricoles, les cyclistes et promeneurs à
>> pied) il n'y a le plus souvent aucun marquage, c'est une chaussée unique où
>> on roule au milieu parce que c'est la meilleure bande de roulement et les
>> cotés sont peu ou pas stabilisés (on doit ralentir très fortement pour se
>> croiser au pas, en roulant dans les gravillon ou sur la pelouse et dans des
>> flaques de boue et sur les morceaux de bitume qui se détachent de la
>> bordure, avec un des véhicules qui doit se garer prudemment sur le bas côté
>> et redémarrer doucement pour ne pas s'enliser dans la boue ou creuser
>> davantage des ornières ou de projeter les cailloux, une seule roue sur la
>> chaussée assurant la traction).
>>
>> Philippe
>>
>>
>> Le 19 août 2017 à 01:49, <osm.sanspourr...@spamgourmet.com> a écrit :
>>
>>> Pas très cohérent.
>>>
>>> Vous distinguez le marquage interne ou/et externe. OK
>>>
>>> Mais dans l'interne vous distinguez le Z/papillon du reste.
>>>
>>> Par contre vous ne distinguez pas en externe le trait long du trait
>>> court.
>>>
>>> Voir
>>> https://fr.wikipedia.org/wiki/Signalisation_routi%C3%A8re_horizontale
>>> ou mieux https://en.wikipedia.org/wiki/Road_surface_marking et
>>>
>>> et sinon pour un tag surface_marking:FR
>>>
>>>
>>> https://fr.wikipedia.org/wiki/Signalisation_routi%C3%A8re_horizontale_en_France
>>>
>>> Il vaut mieux prendre toutes les voies de gauche à droite dans le sens
>>> du way/
>>> none|none|none : double sens étroit.
>>> dash|continuous|dash : marquage de rives avec une ligne continue.
>>>
>>> On dit qu'on a un cas de plus que de voies.
>>>
>>> Je crois qu'il y a déjà des propositions mais je n'ai pas retrouvé.
>>> Ou j'ai juste déjà lu le dernier lien.
>>>
>>> Jean-Yvon
>>>
>>>
>>> Le 18/08/2017 à 23:10, djakk djakk - djakk.dj...@gmail.com a écrit :
>>>
>>> Exemple de marquage en Z :
>>> https://www.mapillary.com/map/im/JdyGWzh-kFVK1Vc1PTDh_w
>>> Exemple de "axial_only" :
>>> https://www.mapillary.com/map/im/r5rG4Crvps9LVHbY-G9eBw
>>> Un peu plus loin sur la même route, ça s'élargit : "shore_and_axial" :
>>> https://www.mapillary.com/map/im/6inui7q7jGH5TNhZBYafHA
>>> "Shore_only" (typique de la Provence) :
>>> https://www.mapillary.com/map/im/xeSE_1GqqDcKPQMWOR0vtg
>>>
>>>
>>> Le ven. 18 août 2017 à 22:27, djakk djakk <djakk.dj...@gmail.com> a
>>> écrit :
>>>
>>>> Alors non, ça serait surface_marking=shore_and_axial | axial_only |
>>>> shore_only | small_axial (small axial pour les marquages en Z)
>>>>
>>>>
>>>> Le ven. 18 août 2017 à 21:42, Philippe Verdy <verd...@wanadoo.fr> a
>>>> écrit :
>>>>
>>>>> Tu donc suggères un tag de type "lanes:separator=line|dashes|marks" ou
>>>>> "lanes:crossing=forbidden|permissive|indicative" ?
>>>>>
>>>>> Le 18 août 2017 à 18:42, djakk djakk <djakk.dj...@gmail.com> a écrit :
>>>>>
>>>>>>

Re: [OSM-talk-fr] Tagger le marquage routier

[djakk djakk]

Alors je distingue le Z/papillon du reste car mon but est d'estimer la
largeur de la route en fonction de son marquage routier. Et ce marquage-ci
n'existe que pour les routes à "2 voies très étroites".

Autrement, on pourrait carrément avoir une clé "type de largeur" avec comme
valeurs "voies larges" "largeur moyenne" "voies étroites" "voies très
étroites" (à traduire en anglais bien sûr :)) combiné à la clé "lanes".
Info à traduire du marquage routier de la route.

Ça me semble mieux d'ailleurs, car le marquage Z/papillon n'existe pas
forcément.


Le sam. 19 août 2017 à 01:50, <osm.sanspourr...@spamgourmet.com> a écrit :

> Pas très cohérent.
>
> Vous distinguez le marquage interne ou/et externe. OK
>
> Mais dans l'interne vous distinguez le Z/papillon du reste.
>
> Par contre vous ne distinguez pas en externe le trait long du trait court.
>
> Voir https://fr.wikipedia.org/wiki/Signalisation_routi%C3%A8re_horizontale
> ou mieux https://en.wikipedia.org/wiki/Road_surface_marking et
>
> et sinon pour un tag surface_marking:FR
>
>
> https://fr.wikipedia.org/wiki/Signalisation_routi%C3%A8re_horizontale_en_France
>
> Il vaut mieux prendre toutes les voies de gauche à droite dans le sens du
> way/
> none|none|none : double sens étroit.
> dash|continuous|dash : marquage de rives avec une ligne continue.
>
> On dit qu'on a un cas de plus que de voies.
>
> Je crois qu'il y a déjà des propositions mais je n'ai pas retrouvé.
> Ou j'ai juste déjà lu le dernier lien.
>
> Jean-Yvon
>
>
> Le 18/08/2017 à 23:10, djakk djakk - djakk.dj...@gmail.com a écrit :
>
> Exemple de marquage en Z :
> https://www.mapillary.com/map/im/JdyGWzh-kFVK1Vc1PTDh_w
> Exemple de "axial_only" :
> https://www.mapillary.com/map/im/r5rG4Crvps9LVHbY-G9eBw
> Un peu plus loin sur la même route, ça s'élargit : "shore_and_axial" :
> https://www.mapillary.com/map/im/6inui7q7jGH5TNhZBYafHA
> "Shore_only" (typique de la Provence) :
> https://www.mapillary.com/map/im/xeSE_1GqqDcKPQMWOR0vtg
>
>
> Le ven. 18 août 2017 à 22:27, djakk djakk <djakk.dj...@gmail.com> a
> écrit :
>
>> Alors non, ça serait surface_marking=shore_and_axial | axial_only |
>> shore_only | small_axial (small axial pour les marquages en Z)
>>
>>
>> Le ven. 18 août 2017 à 21:42, Philippe Verdy <verd...@wanadoo.fr> a
>> écrit :
>>
>>> Tu donc suggères un tag de type "lanes:separator=line|dashes|marks" ou
>>> "lanes:crossing=forbidden|permissive|indicative" ?
>>>
>>> Le 18 août 2017 à 18:42, djakk djakk <djakk.dj...@gmail.com> a écrit :
>>>
>>>> "width" est exclusivement en numérique, je préférerai une clé qui
>>>> permette des valeurs textuelles … dont on pourra éventuellement en déduire
>>>> une valeur "width" selon les standards en vigueur.
>>>>
>>>> Le 18 août 2017 à 16:03, Jo <winfi...@gmail.com> a écrit :
>>>>
>>>>> Il y a aussi le tag width
>>>>>
>>>>> On Aug 18, 2017 15:42, "marc marc" <marc_marc_...@hotmail.com> wrote:
>>>>>
>>>>>> Le 18. 08. 17 à 10:50, djakk djakk a écrit :
>>>>>> > Je me demande si il ne serait pas intéressant de tagger le marquage
>>>>>> > routier afin d'estimer la largeur d'une route
>>>>>> est-ce qu'utiliser "lanes" ne serrait-il pas un bon début ? je me rend
>>>>>> compte seulement maintenant que highway=residential n'as pas de valeur
>>>>>> "lanes" par défaut. j'avais mis des lanes=1 ou 3 là oü c'était
>>>>>> applicable mais pas de lanes=2 pour les autres.
>>>>>> il y a aussi la valeur controversée 1.5 pour indiquer qu'il est
>>>>>> nécessaire d’empiéter sur le bas côté pour se croiser
>>>>>>
>>>>>> ceci dit, dans le rendu par défaut, lanes=1 ou lanes=3 ont la même
>>>>>> apparence. avant de rajouter des tag ce serrait peut-être utile de
>>>>>> voir
>>>>>> si c'est possible d'améliorer le rendu des tag existants
>>>>>> ___
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>> ___
>>>> 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
>>>
>>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
> ___
> 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] références multiple d'une route

[djakk djakk]

Salut,

tu mets ref=N 1;D 1 :
https://www.openstreetmap.org/way/92064133#map=18/42.29784/-71.41703


djakk

Le 19 août 2017 à 17:16, Philippe Verdy  a écrit :

> On peut avoir une départementale récente dont les panneaux n'ont pas
> encore changé. Si ça perdure, on peut imaginer un "new_ref=*" (mettre une
> "note=*" pour commenter que la départementale n'existe que dans les textes
> mais pas encore marquée comme telle sur le terrain).
> Changer tous les panneaux a un coût, et notamment ceux sur les routes
> communales qui n'ont pas forcément obtenu les aides nécessaires pour
> financer ça (aides de l'état pour ôter la référence à l'ancienne nationale,
> ou du département, voire aussi de la région qui peut être concernée par ce
> changement sur plusieurs de ses départements et dans pas mal de communes
> rurales autour).
>
> En revanche le marquage des numéros sur la départementale sera à la charge
> du département lui-même qui lui aussi peut tarder s'il attend les aides de
> l'état qui a du les lui promettre lors du transfert de compétence. Mais on
> sait que l'état est mauvais payeur pour les collectivités locales et
> revient régulièrement sur ses engagements financiers pour les repousser aux
> calendes.
> Le transfert de charge peut donc être refusé sur des sections de la
> nouvelle départementale prévue tant que l'Etat n'a pas financé les travaux
> nécessaires.
>
> Cela justifierait alors un "new_ref=*" ou "ref:project=*" si ce transfert
> n'est pas encore effectif. Une visite sur un site de référence de
> l'équipement départemental pourrait aider à y voir clair (pas seulement les
> arrêtés préfectoraux qui entérinent les décisions de l'Etat mais aussi le
> site du conseil départemental pour qu'il statue sur la finalisation du
> transfert et accepte la prise en charge complète et fixe un calendrier de
> déploiement de la signalisation et reçoive les demandes des communes à
> financer, et notamment les toutes petites communes rurales qui peuvent
> aussi avoir peine à obtenir des aides de leur EPCI tout aussi dénué de
> moyens que ses communes membres)
>
>
>
> Le 19 août 2017 à 17:00, David Crochet  a écrit :
>
>> Bonjour
>>
>>
>> Le 19/08/2017 à 16:45, marc marc a écrit :
>>
>>> Elle a à la fois un numéro de route nationale et une numéro de route
>>> départementale.
>>>
>> Cela ne me semble pas logique, il y a séparation de compétence entre la
>> DDT et le CD sur la voirie, donc l'un est peut-être le nom "officiel"
>> (ref=*) et l'autre "l'ancien nom" (old_ref=*)
>>
>> Cela se trouve où ta situation ?
>>
>> Cordialement
>>
>> --
>> David Crochet
>>
>>
>>
>> ___
>> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Trunk

[djakk djakk]

Il y a aussi l'intérêt d'une harmornisation des définitions de "trunk"
entre les différents pays du monde ; j'ai lancé en parallèle une discussion
sur t...@openstreetmap.org à ce sujet.


djakk

Le dim. 20 août 2017 à 14:59, djakk djakk <djakk.dj...@gmail.com> a écrit :

> Merci Christian, effectivement on aurait besoin d'un niveau de plus pour
> avoir une hiérarchisation plus fine. Et le classement du réseau breton en
> "autoroute osm", j'approuve !
>
>
> djakk
>
> Le dim. 20 août 2017 à 13:36, Christian Rogel <
> christian.ro...@club-internet.fr> a écrit :
>
>>
>> Le 2017 Eost 18 à 12:20, djakk djakk <djakk.dj...@gmail.com> a écrit :
>>
>> Salut,
>>
>> Je reviens sur ce sujet épineux qu'est la classification "trunk".
>>
>> Moi je serai pour utiliser la définition anglaise et japonaise (un niveau
>> de classification de route parmi les autres, au-dessus de primary).
>> Par exemple l'axe est-ouest N175-N176-E401 du côté de Saint-Malo serait
>> intégralement en "trunk" malgré les traversées de villages et les portions
>> à 2*2 voies pas aux normes (pas de bande d'arrêt d'urgence, pas de
>> classification "route pour automobiles" donc ouvert aux vélos et aux
>> piétons).
>>
>> Sinon "trunk" serait réservé aux 2*2 voies, dénivelées ou non (car même
>> si c'est non dénivelé, ouvert aux véhicules agricoles et aux vélos la
>> limitation par défaut d'une 2*2 voies est 110km/h).
>>
>> Je ne vois pas de 3e option.
>>
>> But du jeu = mettre à jour le Wiki qui est contradictoire ;)
>>
>>
>> Ayant déjà soulevé cette question, je rappelle ma vision du problème :
>>
>>- dans la mesure où la réglementation évolue, soit vers une
>>différenciation (voie rapide vs boulevard urbain, abaissement pour 
>> certains
>>axes), il est de plus plus incohérent de faire de la vitesse autorisée un
>>critère pour juger des qualités des routes. Cela paraît même un peu « old
>>school »
>>- La question est autant de pouvoir surclasser certaines « primary »
>>que de cesser de coller sans réflexion au schéma mental des fonctionnaires
>>de l’Équipement qui n’ont pasque des critères routiers, quand ils
>>différencient (et l’IGN les suit, bien sûr) les voies express des
>>autoroutes, alors que l’expérience conducteur le dément
>>- On peut, soit reclasser comme « motorway » certaines liaisons 2 x 2
>>(réseau breton, charentais, N 4, etc.), soit les classer classer
>>« motorroad » l(est-il normal que nous n’utilisions pas cet attribut ?)
>>- Décaler la qualification des niveaux supérieurs donnerait des
>>marges pour hiérarchiser plus finement les autres voies
>>
>>
>>
>> Christian R.
>> ___
>> 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] Trunk

[djakk djakk]

Cela dit, l'idéal serait de distinguer importance du réseau et type de
route : on pourrait avoir des "motorway primary" et des "motorway
secondary" (ou plutôt des "motorway trunk" et des "motorway primary"),
exemple avec l'A106 en région parisienne qui pourrait être qualifiée
d'autoroute secondaire.

Mais, évoluons petit à petit :)


Le dim. 20 août 2017 à 15:09, djakk djakk <djakk.dj...@gmail.com> a écrit :

> Il y a aussi l'intérêt d'une harmornisation des définitions de "trunk"
> entre les différents pays du monde ; j'ai lancé en parallèle une discussion
> sur t...@openstreetmap.org à ce sujet.
>
>
> djakk
>
> Le dim. 20 août 2017 à 14:59, djakk djakk <djakk.dj...@gmail.com> a
> écrit :
>
>> Merci Christian, effectivement on aurait besoin d'un niveau de plus pour
>> avoir une hiérarchisation plus fine. Et le classement du réseau breton en
>> "autoroute osm", j'approuve !
>>
>>
>> djakk
>>
>> Le dim. 20 août 2017 à 13:36, Christian Rogel <
>> christian.ro...@club-internet.fr> a écrit :
>>
>>>
>>> Le 2017 Eost 18 à 12:20, djakk djakk <djakk.dj...@gmail.com> a écrit :
>>>
>>> Salut,
>>>
>>> Je reviens sur ce sujet épineux qu'est la classification "trunk".
>>>
>>> Moi je serai pour utiliser la définition anglaise et japonaise (un
>>> niveau de classification de route parmi les autres, au-dessus de primary).
>>> Par exemple l'axe est-ouest N175-N176-E401 du côté de Saint-Malo serait
>>> intégralement en "trunk" malgré les traversées de villages et les portions
>>> à 2*2 voies pas aux normes (pas de bande d'arrêt d'urgence, pas de
>>> classification "route pour automobiles" donc ouvert aux vélos et aux
>>> piétons).
>>>
>>> Sinon "trunk" serait réservé aux 2*2 voies, dénivelées ou non (car même
>>> si c'est non dénivelé, ouvert aux véhicules agricoles et aux vélos la
>>> limitation par défaut d'une 2*2 voies est 110km/h).
>>>
>>> Je ne vois pas de 3e option.
>>>
>>> But du jeu = mettre à jour le Wiki qui est contradictoire ;)
>>>
>>>
>>> Ayant déjà soulevé cette question, je rappelle ma vision du problème :
>>>
>>>- dans la mesure où la réglementation évolue, soit vers une
>>>différenciation (voie rapide vs boulevard urbain, abaissement pour 
>>> certains
>>>axes), il est de plus plus incohérent de faire de la vitesse autorisée un
>>>critère pour juger des qualités des routes. Cela paraît même un peu « old
>>>school »
>>>- La question est autant de pouvoir surclasser certaines « primary »
>>>que de cesser de coller sans réflexion au schéma mental des 
>>> fonctionnaires
>>>de l’Équipement qui n’ont pasque des critères routiers, quand ils
>>>différencient (et l’IGN les suit, bien sûr) les voies express des
>>>autoroutes, alors que l’expérience conducteur le dément
>>>- On peut, soit reclasser comme « motorway » certaines liaisons 2 x
>>>2 (réseau breton, charentais, N 4, etc.), soit les classer classer
>>>« motorroad » l(est-il normal que nous n’utilisions pas cet attribut ?)
>>>- Décaler la qualification des niveaux supérieurs donnerait des
>>>marges pour hiérarchiser plus finement les autres voies
>>>
>>>
>>>
>>> Christian R.
>>> ___
>>> 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] Marché

[djakk djakk]

Il y a des emplacements fixes où ce sont les mêmes commerçants tout au long
de l'année, ceux-là seraient intéressant à cartographier je trouve ...
C'est le cas pour les 2 marchés que je connais très bien (dont celui des
Lices à Rennes, un des plus grands)


Le jeu. 17 août 2017 à 14:51, David Crochet <david.croc...@free.fr> a
écrit :

> Bonjour
>
>
> Le 17/08/2017 à 13:35, djakk djakk a écrit :
> > est-ce souhaitable de tagger précisément un marché, stand par stand ?
> > Genre le marché qui a lieu une fois par semaine sur un parking.
> Si c'est un marché à ciel ouvert, je ne fait jamais du stand à stand
> mais seulement un point pour indiquer que le marché est présent avec des
> horaires d'ouverture.
>
> Cordialement
> --
>
> David Crochet
>
>
> ___
> 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] Marché

[djakk djakk]

t; en dur mais l'autre bâtiment (toujours sauf erreur) est vide en temps
>> normal (pouvant servir de salle de spectacle, meeting... à l'occasion) et
>> entre le cœur du marché des Lices et ce marché couvert il ne doit pas y
>> avoir grande différence dans la gestion des emplacements.
>> Pour visualiser : voir lien précédent.
>> Pour donner un ordre de grandeur, le marché des Lices c'est 290
>> professionnels et Wikipédia ne se risque pas à donner les emplacements
>> individuels mais par type d'activité ce qui est déjà bien :
>>
>> https://fr.wikipedia.org/wiki/fr:March%C3%A9%20des%20Lices?uselang=en#/map/0
>>
>> Ils incorporent les deux halles au marché des Lices contrairement à OSM.
>>
>> Je suis entièrement d'accord avec Christian : ne pas maintenir une info
>> c'est pire que ne pas la mettre si elle évolue.
>> Ca dépend donc de la communauté OSM de Rennes.
>>
>> La seule grosse différence que je vois entre marché ouvert et marché
>> couvert c'est que surcharger par des POI des halles/marchés couverts peut
>> prêter à confusion (si on affiche sur la carte, même avec des opening_hours
>> qui vont bien) tandis que sur une surface ayant un usage autre (routes et
>> parkings en particulier) ce n'est pas juste pas acceptable.
>>
>> Jean-Yvon
>>
>>
>> Le 17/08/2017 à 15:18, djakk djakk - djakk.dj...@gmail.com a écrit :
>>
>> Il y a des emplacements fixes où ce sont les mêmes commerçants tout au
>> long de l'année, ceux-là seraient intéressant à cartographier je trouve ...
>> C'est le cas pour les 2 marchés que je connais très bien (dont celui des
>> Lices à Rennes, un des plus grands)
>>
>>
>> Le jeu. 17 août 2017 à 14:51, David Crochet <david.croc...@free.fr> a
>> écrit :
>>
>>> Bonjour
>>>
>>>
>>> Le 17/08/2017 à 13:35, djakk djakk a écrit :
>>> > est-ce souhaitable de tagger précisément un marché, stand par stand ?
>>> > Genre le marché qui a lieu une fois par semaine sur un parking.
>>> Si c'est un marché à ciel ouvert, je ne fait jamais du stand à stand
>>> mais seulement un point pour indiquer que le marché est présent avec des
>>> horaires d'ouverture.
>>>
>>> Cordialement
>>> --
>>>
>>> David Crochet
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>> ___
>> Talk-fr mailing 
>> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>>
>> ___
>> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Trunk

[djakk djakk]

Salut,

Je reviens sur ce sujet épineux qu'est la classification "trunk".

Moi je serai pour utiliser la définition anglaise et japonaise (un niveau
de classification de route parmi les autres, au-dessus de primary).
Par exemple l'axe est-ouest N175-N176-E401 du côté de Saint-Malo serait
intégralement en "trunk" malgré les traversées de villages et les portions
à 2*2 voies pas aux normes (pas de bande d'arrêt d'urgence, pas de
classification "route pour automobiles" donc ouvert aux vélos et aux
piétons).

Sinon "trunk" serait réservé aux 2*2 voies, dénivelées ou non (car même si
c'est non dénivelé, ouvert aux véhicules agricoles et aux vélos la
limitation par défaut d'une 2*2 voies est 110km/h).

Je ne vois pas de 3e option.

But du jeu = mettre à jour le Wiki qui est contradictoire ;)


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

[OSM-talk-fr] Tagger le marquage routier

[djakk djakk]

Salut,

Je me demande si il ne serait pas intéressant de tagger le marquage routier
afin d'estimer la largeur d'une route : alors il ne s'agit pas de tagger le
type de marquage (ligne continue, pointillés ...) mais la quantité de
marquage au sol = au centre, à proximité des accotements : une route large
a 3 marquages au sol, 2 sur les accotements, 1 au centre. Une route de
largeur moyenne n'a que du marquage au centre, et une route peu large n'a
pas du tout de marquage au sol ...

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

Re: [OSM-talk-fr] Marché

[djakk djakk]

À Rennes les emplacements des commerçants habitués sont fixes y compris en
extérieur :
http://metropole.rennes.fr/pratique/infos-demarches/economie-commerce-consommation/vendre-sur-les-marches-rennais/


Le ven. 18 août 2017 à 12:46, Philippe Verdy <verd...@wanadoo.fr> a écrit :

> Le 18 août 2017 à 10:35, djakk djakk <djakk.dj...@gmail.com> a écrit :
>
>> Le jeu. 17 août 2017 à 22:12, Philippe Verdy <verd...@wanadoo.fr> a
>> écrit :
>>
>>> J'ai le même avis. Hormis les emplacements fixes dans les halles
>>> couvertes, qui sont loués avec un bail à l'année, tout le reste est
>>> déterminé par le placier chaque jour de marché : tant pis pour ceux qui
>>> sont en retard.
>>
>>
>
>> Pour le côté "impermanence", on a bien cartographié les bureaux de vote
>> et les panneaux électoraux :)
>>
>
> Oui mais les emplacements des panneaux électoraux ne sont pas à
> disposition pour autre chose même s'ils ne sont pas utilisés. Leur
> emplacement reste réservé. Les bureaux de vote sont établis au minimum à
> l'année (l'adresse figure sur la carte d'électeur envoyée en début d'année,
> leur nombre est également figé par la clôture le 31 décembre et la
> validation des listes électorales en janvier).
>
> Les emplacements de marché, leur métrage est déterminé le jour même selon
> les marchands présents... à la seule exception des emplacements fixes des
> marché couverts, qui ont des baux annuels et du matériel en place qui leur
> appartient et qu'ils entretiennent, ce qui n'autorise pas d'autres
> marchands à s'y installer même si le jour du marché il n'est pas présent.
> Ces emplacements ont souvent des enseignes fixées à leur nom.
> ___
> 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] Présentation

[djakk djakk]

Salut, pour faire ma carte des routes et des villes européennes (
http://itineraires.de.bus.free.fr/carte-des-routes-europeennes-2016/index.html?7,3.16406,47.6690)
(avec mapnik) tout est automatisé, mais j'ai une étape dans mon programme
qui filtre le nom des villes selon la taille des villes à proximité, chose
qui n'est pas possible de faire directement dans une feuille de style
mapnik ou (je suppose) dans qgis. C'est peut être ça "l'outil" qui manque,
un travail sur les données osm juste avant le rendu.

Julien "djakk"

Le 20 juin 2017 à 20:10, JB  a écrit :

> Bonsoir bonsoir,
> Après réflexion, j'ai quand même envie de mettre mon grain de sel dans la
> discussion avec une question principale : « Pourquoi QGis ? »
> C'est une question sérieuse. Est-ce après comparaison d'alternatives, ou
> juste parce que c'est l'outil auquel on est habitué ?
> En fait, la carte papier a été évoquée plusieurs fois à Avignon, avec à
> chaque fois cette observation : c'est plus compliqué que ce qu'on pourrait
> penser. Et à chaque fois, il a été observé qu'il ne semblait pas réaliste
> d'automatiser intégralement la chaine de production. Que pour une qualité
> correcte, un humain devait intervenir quelque part. Pour la carte de
> Digne-les-Bains par exemple, la plus grosse partie de placement
> d'étiquettes a été fait dans Illustrator (j'espère ne pas déformer
> l'information, c'est ce que j'en ai compris). Dans la présentation de carte
> de randonnée, les replacements d'étiquettes étaient réalisés dans la
> feuille de style. Thomas indiquait que si QGis pouvait replacer des
> étiquettes, une intervention humaine pouvait également être possible ou
> nécessaire. Charles indiquait qu'il avait également passé un bout de temps
> à placer des étiquettes pour la carte de Clermont-Ferrand l'année dernière.
> Du coup, avec le recul, entre l'importation des données et le coté
> relativement laborieux du travail dans QGis, la galère de la chaine
> d'utilisation Mapnik, les défauts de Maperitive, je me dis qu'il doit
> encore manquer un outil quelque part.
> Mais quand même : quand on a l'habitude de travailler avec les tags OSM,
> la feuille de style Maperitive, c'est top.
> Voilà voilà,
> JB.
>
>
> Le 20/06/2017 à 14:53, Carto SIG a écrit :
>
>> Bonjour Emeric,
>>
>> Bienvenue. Cela me fait penser que de manière très malpolie, je ne me
>> suis pas présenté en arrivant sur la liste et dans OSM il y a un peu moins
>> de 2 ans. Je travaille pour le SIG d'une collectivité (Pays de Redon -
>> Bretagne Sud) et on utilise OSM dans le cadre professionnel avec différents
>> objectifs notamment produire des plans papiers (plan de ville, fond de plan
>> 1/10e, plan de localisation) et faire des relevés sur l'accessibilité
>> de la ville de Redon avec OSM et Mapcontrib (projet cartomobilité). En
>> complément, on contribue aussi à Mapillary. Je ferme la parenthèse.
>>
>> Emeric, tu es peut être déjà tombé sur les tutos d'Anita Graser (mais les
>> styles de Charles sont de l'excellent travail bien évidemment, on va
>> probablement basculer à l'occasion ;) ):
>> https://anitagraser.com/2014/05/31/a-guide-to-googlemaps-lik
>> e-maps-with-osm-in-qgis/
>>
>> La méthode utilisée pour le plan de ville de Digne-les-Bains tombe
>> également bien dans le cadre de ce que tu veux faire (usage de Qgis avec
>> les styles de Charles), elle a été présentée au dernier SOTM, j'espère
>> qu'on peut la retrouver en ligne.
>>
>> JB avait aussi présenté un beau rendu que tu retrouveras dans la liste de
>> discussion mais il utilisait Maperitive alors cela sort un peu de ton cadre
>> (et du mien).
>>
>> Bref, n'hésite pas à partager le résultat de ton travail, cela
>> m'intéresse (et plein d'autres certainement). On a notamment un office de
>> tourisme qui sera forcément ravi qu'on puisse lui réaliser plus facilement
>> des plans des sentiers de randonnée. D'ailleurs, est-ce que quelqu'un
>> connait d'autres fichiers de styles pour Qgis prévus pour les données OSM
>> (en dehors de ceux déjà cités de Charles, d'Anita Graser et de Charley
>> Glynn : https://github.com/charleyglynn/OSM-Shapefile-QGIS-stylesheets)
>> ? Ce serait sympa d'avoir une bibliothèque de styles OSM pour Qgis.
>>
>> Bonne journée à tous,
>> Etienne Chauchaix
>> s...@pays-redon.fr
>>
>> --
>>
>> Message: 1
>> Date: Mon, 19 Jun 2017 14:55:05 +0200
>> From: Charles MILLET 
>> To: talk-fr@openstreetmap.org
>> Subject: Re: [OSM-talk-fr] Présentation
>> Message-ID: <86f2bb50-2d90-17d4-dcdc-23a3ad0fd...@free.fr>
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>
>> Bonjour Émeric,
>>
>> Bienvenu sur la liste.
>>
>> On partage quelques centres d'intérêt : je pousse depuis quelques temps
>> des méthodes de production de cartes sous QGIS à partir de données OSM,
>> n'hésite pas à regarder le tuto que j'ai rédigé et les styles attachés (
>> 

Re: [OSM-talk-fr] Communes pratiquant l'extinction de l'éclairage public

[djakk djakk]

Sur le wiki il y a bien cet exemple, *lit*=Mo-Fr 05:00-07:45 (
http://wiki.openstreetmap.org/wiki/Key:lit) ; mais il faudrait une valeur
quand on ne connaît pas les horaires exactes.

Le 30 avril 2017 à 20:51, Christian Quest <cqu...@openstreetmap.fr> a écrit
:

> Un tag pour indiquer les plages horaires où c'est éteint ?
>
> lit=no@22:00-06:00 ? Un peu bricolé, il va falloir un autre tag...
>
> Le 30 avril 2017 à 10:52, djakk djakk <djakk.dj...@gmail.com> a écrit :
>
>> Salut,
>>
>> dans ma commune seules quelques rues sont concernées, du coup il faudrait
>> tagguer rue par rue, avec la clé "lit=" ; pour la valeur, à voir …
>>
>> Julien djakk (http://itineraires.de.bus.free.fr)
>>
>> Le 30 avril 2017 à 10:21, Paul Desgranges <paul.desgran...@gmail.com> a
>> écrit :
>>
>>> Bonjour,
>>>  Existe-t-il / est-il souhaitable / est-il possible de rajouter un tag
>>> sur les communes qui pratiquent l'extinction de l'éclairage public
>>> <https://commons.wikimedia.org/wiki/File:Panneau_d%27extinction_de_l%27%C3%A9clairage_public.jpg>
>>> ?
>>>  Merci
>>>
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> 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] ***SPAM*** Re: Nationale N79

[djakk djakk]

Allez, je lance un vote sur l'évolution ou non du tag "trunk" :), le mieux
c'est sur la mailing-list, sur le forum ou sur le wiki ?

Le 28 avril 2017 à 18:01, djakk  a écrit :

> Oui effectivement Jérôme, "primary", "secondary", "tertiary" et
> "unclassified" sont basés sur la densité de trafic alors que "trunk" et
> "motorway" - en France - sont basés sur les caractéristiques de la voie.
> Les cartes Michelin font la distinction, la caractéristique de la voie est
> représentée par la largeur du trait et la densité de trafic par la couleur.
> Mais en Angleterre, au Japon et aux États-Unis
> (https://www.openstreetmap.org/#map=17/40.73000/-74.04023), "trunk" est
> basé
> sur la densité de trafic !
>
> Alors 2 choix s'offrent à nous, soit on garde la spécificité française et
> tout ce qui est à 2*2 voies est "trunk" ou "motorway", soit on rejoint la
> définition majoritairement utilisée dans le monde et tout ce qui est route
> nationale et/ou européenne en France est "trunk" si pas déjà "motorway".
> Simple ! :-)
>
>
>
> --
> View this message in context: http://gis.19327.n8.nabble.
> com/Re-SPAM-Re-Nationale-N79-tp5896036p5896060.html
> Sent from the France mailing list archive at Nabble.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] Communes pratiquant l'extinction de l'éclairage public

[djakk djakk]

lit=curfew (couvre-feu) ?

Le 30 avril 2017 à 21:08, djakk djakk <djakk.dj...@gmail.com> a écrit :

> Sur le wiki il y a bien cet exemple, *lit*=Mo-Fr 05:00-07:45 (
> http://wiki.openstreetmap.org/wiki/Key:lit) ; mais il faudrait une valeur
> quand on ne connaît pas les horaires exactes.
>
> Le 30 avril 2017 à 20:51, Christian Quest <cqu...@openstreetmap.fr> a
> écrit :
>
>> Un tag pour indiquer les plages horaires où c'est éteint ?
>>
>> lit=no@22:00-06:00 ? Un peu bricolé, il va falloir un autre tag...
>>
>> Le 30 avril 2017 à 10:52, djakk djakk <djakk.dj...@gmail.com> a écrit :
>>
>>> Salut,
>>>
>>> dans ma commune seules quelques rues sont concernées, du coup il
>>> faudrait tagguer rue par rue, avec la clé "lit=" ; pour la valeur, à voir …
>>>
>>> Julien djakk (http://itineraires.de.bus.free.fr)
>>>
>>> Le 30 avril 2017 à 10:21, Paul Desgranges <paul.desgran...@gmail.com> a
>>> écrit :
>>>
>>>> Bonjour,
>>>>  Existe-t-il / est-il souhaitable / est-il possible de rajouter un tag
>>>> sur les communes qui pratiquent l'extinction de l'éclairage public
>>>> <https://commons.wikimedia.org/wiki/File:Panneau_d%27extinction_de_l%27%C3%A9clairage_public.jpg>
>>>> ?
>>>>  Merci
>>>>
>>>>
>>>> ___
>>>> 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
>>>
>>>
>>
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>> ___
>> 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] Comptage trafic routier

[djakk djakk]

>> Quoi que le comptage permettrait effectivement de placer l'usage en tout
premier plan.

En fait, j'ai déjà appliqué cette idée il y a 1 an sur les routes de
Bretagne (celle à 5 départements ^^), parmi les effets un peu bizarre ça
donne de nombreuses "primary" à proximité de la mer (reflet de l'attirance
du littoral) (https://www.openstreetmap.org/#map=13/48.6484/-1.9302), ou
des "interruptions" de style sur une même route, ça passe de "primary" à
"secondary" à "tertiary" plus on s'éloigne d'une grande ville. (
https://www.openstreetmap.org/#map=13/47.8404/-1.8239 ;
https://www.openstreetmap.org/#map=13/48.2240/-1.7055)

Mes critères étaient : routes < 2000 véhicules / jour -> "tertiary" ; <
5000 véhicules / jour -> "secondary"; sinon primary


Le 30 avril 2017 à 14:55,  a écrit :

> > Je préfère ajouter un code wikidata et joindre avec une base ayant un
> rythme de mise à jour différent pour récupérer ces données.
> C'est l'idée du schéma TMC (avec mise à jour sur OpenEventDataBase
>  par
> exemple).
>
> Jean-Yvon
>
>
> ___
> 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] Comptage trafic routier

[djakk djakk]

>
> Pour la portion de D82 en question, comme elle relie une grande ville avec
> une petite et qu'on a à proximité une voie rapide, un highway=secondary
> serait cohérent, tout comme entre Guipel et Dingé où c'est toujours de la 2
> voies larges. Elle forme un itinéraire de Rennes > Guipel > Dingé >
> Combourg, ensuite c'est la D795 (un ancienne nationale ?) qui prend le
> relai jusque Dol-de-Bretagne.


Effectivement, au premier abord, la D82 semble former l'itinéraire "Rennes
à Combourg" ; mais les chiffres de comptage du trafic routier permettent
d'affiner cette analyse, il montrent que le trafic Rennes - Combourg passe
en grosse majorité par la D795 et la D137 (détour pour prendre la 2*2
voies). En fait, la D82 n'est que l'itinéraire Rennes - Dingé …

Quelques chiffres : 1300 véhicules par jour entre Guipel et Dingé sur la
D82, 4700 sur la D795 entre Combourg et la D137 (Carte 2014 des trafics
moyens journaliers sur le réseau routier national et départemental en
Ille-et-Vilaine

)


A trop se baser sur les comptages, on n'aura que des primary en périphérie
> des grandes villes et on perdra toute notion d'itinéraire au délà.


Oui, c'est vrai qu'il faut en premier lieu éviter d'avoir des primary
partout, moi j'adapte les seuils liés au comptage de trafic à proximité des
grandes villes (à l'intérieur de la 2e ceinture pour Rennes).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Comptage trafic routier

[djakk djakk]

Malheureusement je n'ai jamais vu une carte avec les chiffres de
fréquentation des artères d'une ville … alors que ça se trouve plus ou
moins facilement pour les départements, selon les départements.

Le 2 mai 2017 à 21:58, Christian Quest <cqu...@openstreetmap.fr> a écrit :

> Le 2 mai 2017 à 11:08, djakk djakk <djakk.dj...@gmail.com> a écrit
>
>> Oui, c'est vrai qu'il faut en premier lieu éviter d'avoir des primary
>> partout, moi j'adapte les seuils liés au comptage de trafic à proximité des
>> grandes villes (à l'intérieur de la 2e ceinture pour Rennes).
>>
>>
> là ça me semble un indicateur intéressant car en agglomération il n'est
> pas facile de faire la classification. Dans Paris ce n'est pas aussi
> évident que ça, même si la logique d'itinéraire peut s'appliquer en
> changeant d'échelle elle n'est pas toujours claire.
>
>
> Il y a cette clé, "traffic" pour les ways, valeurs : low, intermediate,
>> heavy, fast (vue sur taginfo mais pas sur le wiki) …
>>
>
> C'est à mon avis plus pertinent de l'utiliser que de bricoler les highway=*
>
> De plus, un calculateur d'itinéraire pourrait tenir compte de l'ensemble
> de tags traffic + lanes et autres tags indiquant des feux tricolores,
> ralentisseurs, carrefours pour évaluer la fluidité du traffic et adapter
> ses choix.
>
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> 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] Comptage trafic routier

[djakk djakk]

Effectivement, on ne peut pas faire grand chose avec un point de comptage,
et puis il faut une analyse humaine pour comprendre que ça s'applique entre
tel et tel carrefour important.

Il y a cette clé, "traffic" pour les ways, valeurs : low, intermediate,
heavy, fast (vue sur taginfo mais pas sur le wiki) …

Le 2 mai 2017 à 12:58, Yannick  a écrit :

> Le 29/04/2017 à 21:27, djakk a écrit :
>
>> Salut,
>>
>> est-ce que les comptages de trafic routier réalisés par les DIR ou les
>> départements peuvent être utilisés pour définir les types de "highway"
>> (on a
>> le droit ? c'est intéressant ?) (exemple avec l'Ille-et-Vilaine :
>> http://www.ille-et-vilaine.fr/sites/default/files/asset/docu
>> ment/carte_2014_des_trafics_moyens_journaliers_sur_les_
>> routes_departementales_et_nationales_en_ille-et-vilaine.pdf)
>> Et est-il possible/souhaitable d'intégrer un comptage dans osm (sous la
>> forme d'un nœud) ?
>>
>> Julien "djakk" (http://itineraires.de.bus.free.fr)
>>
>
> Bonjour,
>
> Je ne pense pas qu'il faille lié trafic et type de voie.
> Par contre rien n'empêche d'avoir un tag avec ces éléments:
> Compteur: xx
> Référence: Source du comptage
> Date: Date du comptage
>
> Maintenant il y a un truc qui semble avoir été oublié dans ce fil. Le
> point de comptage n'est pas permanent, ensuite ce n'est pas 1 point mais
> plusieurs qui sont liés pour faire une étude de trafic et adapter les
> infrastructures.
> Il ne faut pas oublier non plus que les points de comptages évoluent avec
> les moyens techniques, donc moins visibles.
>
> Si demain le péage de Condrieu/Sainte-Colombe, en face de Vienne,
> disparait ET que les sorties de Reventin sont enfin crées, on aura de suite
> un déplacement du trafic sur ce tronçon autoroutier, qui deviendra trunk de
> facto, et fera baisser énormément le trafic dans la traversée de Vienne le
> long du Rhône et pourtant cette section de route restera en trunk puis
> primary.
>
> Amitiés
>
> --
> Yannick VOYEAUD
> Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
> (Camille JOUFFRAY 1841-1924, maire de Vienne)
> http://www.voyeaud.org
> Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
> Journées du Logiciel Libre: http://jdll.org
> Généalogie en liberté avec Ancestris http://www.ancestris.org
> Aidez Ancestris à aller au Havre
> https://www.helloasso.com/associations/ancestris/collectes/le-havre-2017
>
>
> ___
> 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] Comptage trafic routier

[djakk djakk]

>> Et pourquoi prioriser le comptage ?

Je trouve que le comptage est à la source de tout :-) : le décideur l'a
utilisé pour les aménagements routiers (largeur des voies, nombre de voies,
suppression des carrefours à niveau, …) ; c'est aussi le signe du meilleur
itinéraire possible dans le réseau, si la majorité des gens passent par là
c'est que c'est le bon itinéraire.


Avec ta technique, comment tagguerais-tu la D82 ?

Le 1 mai 2017 à 22:57, Christian Quest  a écrit :

> Le 1 mai 2017 à 21:46, djakk  a écrit :
>
>> Le wiki est assez varié : là on conseille de tagguer selon le trafic :O :
>>
>>
> La référence pour le wiki est l'anglais quand il y a divergence car c'est
> cette version qui est la plus universelle ;)
>
>
> "La valeur de la clé highway ne doit pas dépendre d'un itinéraire routier.
>> Dans de nombreux pays, une section particulière d'une route peut faire
>> partie de plusieurs itinéraires ou réseaux routiers et un itinéraire
>> particulier peut avoir plusieurs sections avec différents attributs et
>> ainsi
>> différents tags highway. Pour la France, ce point concerne par exemple les
>> références de routes (D1, N7, etc) : une même départementale peut avoir
>> des
>> sections en trunk, d'autres sections en primary ou encore secondary,
>> suivant
>> le nombre de voies, la largeur et l'importance du trafic."
>> (http://wiki.openstreetmap.org/wiki/FR:Key:highway)
>>
>
> Ok, le mot traffic apparait, mais c'est vraiment à la marge et pas du tout
> l'élément central pour choisir entre primary/secondary/tertiary.
>
> C'est surtout le passage en trunk qui est justifié par les règles du code
> de la route différente.
> Ce que, à mon avis, ce paragraphe veut surtout souligner c'est qu'une
> route (D1) peut avoir des sections de natures différentes, car l'ensemble
> ne fait pas forcément partie du même niveau de hiérarchie dans le réseau
> même si elle a le même ref=* de bout en bout.
>
> Exemple: de la ville A à B on est en primary, mais de B à C (par exemple
> ville de moindre importance) on est en secondary.
>
>
> >>Par exemple, on ne peut pas comparer la fréquentation de routes proches
>> d'agglomérations avec la même route en zone rurale qui relie deux
>> agglomérations.
>>
>> Oui mais justement, je trouve intéressant de refléter le trafic local :
>> les
>> villes ont une composante péri-urbaine et le périurbain a des artères
>> fortes, lointain reflet des boulevards importants de la ville
>> "traditionnelle" ; exemple, la D82 au nord de Rennes :
>> https://www.openstreetmap.org/#map=15/48.1916/-1.6928 : dans l'exemple,
>> la
>> D82, artère périurbaine forte, n'est pas munie d'un trafic de transit
>> suffisant (la D137 à 2*2 voies le lui a piqué), du coup elle s'estompe,
>> passant progressivement de primary à secondary à tertiary.
>>
>
>
> Avoir une info disponible sur le traffic c'est une chose (et ça peut être
> utile), mais de là à détourner la classification des routes pour cela,
> c'est une toute autre chose.
>
> Il serait préférable d'avoir par exemple un tag traffic=heavy/medium/light
> voire une info de comptage sur le tronçon.
>
> Et pourquoi prioriser le comptage ? Pourquoi ça ne serait pas la vitesse
> moyenne qu'il faudrait utiliser ? De plus ces infos de traffic sont très
> dépendantes du jour et de l'heure...
>
> A mon avis, la classification doit rester neutre par rapport au traffic et
> si on a des infos sur le traffic (comptage, vitesse moyenne), on les fait
> porter par des tags dédiés à ça et un calculateur d'itinéraire pourra
> directement les exploiter plutôt que d'extrapoler le highway=*
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> 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] Zone naturelle protégée, chemin à accès restreint

[djakk djakk]

Salut, pour ta 2e question je mettrai simplement un access=no avec
éventuellement une note= pour expliquer …

Le 16 octobre 2017 à 08:22, Nicolas Toublanc  a écrit
:

> Bonjour,
>
> J'ai 2 questions relatives aux mapping de chemins piétons;
>
> *Question 1)*
>
> Dans une zone naturelle protégée, contenant des chemins pour piétons et
> cyclistes, explicitement interdits aux chevaux et véhicules motorisés, mais
> accessibles au tracteur de service pour l'entretien.
>
> En pratique, quand j'y suis allé il n'y avait que des piétons.
>
> Actuellement, on a les tags:
>
>- highway: path
>- foot: yes
>
> Sur le wiki (http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Acc
> ess-Restrictions#France), je vois qu'un path, en France, est considéré
> par défaut comme accessible aux:
>
>- mobylette
>- chevaux
>- piétons
>- bicyclettes
>
> Donc dans ce cas, je suppose qu'il faut explicitement ajouter:
>
>- bicycle: yes
>- moped: no
>- horse: no
>
> Ou est-ce même plutôt designated qu'il faut utiliser, au lieu de yes (au
> moins pour les piétons) ?
>
> Dans quel cas doit-on plutôt utiliser highway: footway ?
> http://wiki.openstreetmap.org/wiki/Tag:highway%3Dfootway
>
> *Question 2) *
>
> Une partie des chemins sont interdits au public, et appelés "Zone de
> quiétude", pour protéger la faune.
>
> Comment indiquer cette restriction d'accès?
>
>
> Merci de votre aide!
>
>>
>
>
>
> ___
> 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] fin d'une route secondaire ou tertiaire vers un hameau

[djakk djakk]

J'ai pas compris, as-tu le lien direct sur osm ?

Le 12 octobre 2017 à 10:02, marc marc  a écrit :

> Bonjour,
>
> Que faire lorsqu'une route secondaire ou tertiaire raccorde un hameau ?
> le hameau est en highway=unclassified
> j'ai mis la bretelle d'accès à la route secondaire en secondary_link
> mais osmose est d'avis que c'est pas ainsi qu'il faut faire :)
>
> Cordialement,
> Marc
> ___
> 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] GR 5 Jura cartographié ? Et la FFRP ?

[djakk djakk]

Salut, c'est fou ça, j'aurai cru que tant que c'est fléché sur le terrain
on avait droit de "copier" le terrain dans osm (c'est différent de copier
un topoguide du GR 5 ou une carte).

djakk

Le 11 septembre 2017 à 15:43, David Marchal  a écrit :

> Salut, les gens.
>
> Je viens de voir que le GR 5 Jura avait été cartographié (
> https://www.openstreetmap.org/relation/6095322), or il me semblait que,
> dans l’attente d’un accord avec la FFRP concernant l’ajout des GR et de
> leurs autres itinéraires dans OSM, on devait ne pas les ajouter pour éviter
> tout conflit sur leurs droits d’auteurs. Aurais-je manqué un épisode ?
>
> Dans l’attente de vos réponses,
>
> Cordialement.
>
> ___
> 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] le festival de tout les highway :-)

[djakk djakk]

Ben oui c'est un axe très emprunté tout simplement, et tu me demanderais
ton chemin je te conseillerai en toute bonne foi de passer par là malgré la
limitation à 20km/h :)


djakk

Le lun. 21 août 2017 à 22:55, <osm.sanspourr...@spamgourmet.com> a écrit :

> Tes statistiques viendraient d'actuels Rennais peut-être...
>
> Mais là tu mélanges des gens qui ont connu les quais du temps de la
> bagnole reine (sans jeu de mot) et d'autres qui connaissent la situation
> actuelle.
>
> Ce fut un axe important et ça le reste... pour les transports en commun et
> les manifs ;-).
>
> Il ne faut surtout pas conseiller de passer par là donc living_street et
> c'est tout.
>
> La décision de changer le statut de la rue doit se retrouver dans OSM.
>
> Ce qui me semble aberrant c'est de laisser le statut primary (!) aux quais
> Lamartine et Duguay Trouin
> <https://www.openstreetmap.org/way/23162201#map=18/48.11016/-1.68234> de
> part et d'autre.
>
> C'est-à-dire juste en dessous des voies-express !
>
> N.B. : Rennes, c'est la seule ville qui a réussi à boucher (cacher) une
> rivière pour mettre du gravillon à la place ou il y en a d'autres ?
> D'habitude c'est pour mettre des parkings. Là ils ont bouché pour mettre un
> parking puis ont enlevé le parking pour mettre du gravillon. C'est vrai que
> la Vilaine porte bien son nom mais quand même :-D.
>
> Jean-Yvon
>
> Le 21/08/2017 à 21:35, djakk djakk - djakk.dj...@gmail.com a écrit :
>
> Alors une route primaire en même temps living_street c'est simple, tu mets
> ce panneau carré bleu avec des piétons et une "limitation à 20 km/h"
> incrusté (
> https://fr.m.wikipedia.org/wiki/Panneau_de_signalisation_d%27une_zone_de_rencontre_en_France)
> sur un des axes les plus importants d'une ville (quoiqu'en dise Philippe,
> j'ai fait un petit sondage sur la mailing-list bzh c'est un axe "secondary"
> au minimum). ;-)
>
>
> djakk
>
>
>
>
> ___
> 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] le festival de tout les highway :-)

[djakk djakk]

Je connais la situation actuelle. C'est une "primary" avec des limitations
à 20km/h et à 30km/h et un stop sur une rue secondaire, mais c'est toujours
une artère "toute droite" donc pas vraiment décourageant pour les voitures,
pour preuve le gros flot de voitures qu'on y observe en journée ...


djakk

Le lun. 21 août 2017 à 23:52, Philippe Verdy  a écrit :

> Le 21 août 2017 à 22:54,  a écrit :
>
>> Tes statistiques viendraient d'actuels Rennais peut-être...
>>
>> Mais là tu mélanges des gens qui ont connu les quais du temps de la
>> bagnole reine (sans jeu de mot) et d'autres qui connaissent la situation
>> actuelle.
>>
>> Ce fut un axe important et ça le reste... pour les transports en commun
>> et les manifs ;-).
>>
> Tout à fait d'accord.
>
>> Il ne faut surtout pas conseiller de passer par là donc living_street et
>> c'est tout.
>>
>> La décision de changer le statut de la rue doit se retrouver dans OSM.
>>
>> Ce qui me semble aberrant c'est de laisser le statut primary (!) aux
>> quais Lamartine et Duguay Trouin
>>  de
>> part et d'autre. C'est-à-dire juste en dessous des voies-express !
>>
>  D'accord aussi, on ne peut pas garder ça en primary juste en souvenir de
> ce que ça a été: une grosse artère pour automobiles, mais ça ne l'est plus
> du tout, tout a été fait pour décourager la voiture de ce secteur des quais
> par la République
>
>> N.B. : Rennes, c'est la seule ville qui a réussi à boucher (cacher) une
>> rivière pour mettre du gravillon à la place ou il y en a d'autres ?
>> D'habitude c'est pour mettre des parkings. Là ils ont bouché pour mettre un
>> parking puis ont enlevé le parking pour mettre du gravillon. C'est vrai que
>> la Vilaine porte bien son nom mais quand même :-D.
>>
> Pourtant la Vilaine porte mal son nom quand on voit les belles balades que
> font les Rennais depuis longtemps le long de sa vallée. Quel Rennais l'a
> jamais été au moulin du Boël ?
>
> Les Bretonnants ne la voient pas si vilaine que ça, son nom c'est la
> "Gwilen" (l'orthographe varie un peu selon les variétés dialectales du
> breton, mais comme Rennes n'est pas réellement dans la zone historique du
> breton mais celle du gallo, proche du normand, de l'angevin et du poitevin
> et classé dans un continuum parmi les langues d'oïl, contrairement au
> breton d'origine insulaire, le nom de la Vilaine n'a pas toujours été celui
> qu'on lui connait maintenant en "français", une langue créée de toute pièce
> très tardivement sur des bases ligériennes et non parisienne, mais
> uniquement au départ pour la cour royale et qui ne s'est imposée comme
> standard qu'au début de XXe siècle... le breton est beaucoup plus ancien et
> se retrouve depuis plus de 13 siècles un peu partour en Europe du Nord
> jusqu'au royaume de Suède et jusqu'au début du XXe siècle c'était encore
> mutuellement intelligible avec le mannois de l'autre côté de la Manche)
> ___
> 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] Trunk

[djakk djakk]

Complètement d'accord avec toi Jérôme.
J'ai l'impression que ça vient de la culture anglo-saxonne : on retrouvait
les mêmes travers dans le HTML. Mais cet "état d'incohérence" permet de
débuter rapidement un projet. Un Français voudrait que tout soit parfait
dès le départ du projet ce qui prend plus+ de temps.

Pour les voies ferrées, il existe une clé "importance" avec comme valeurs
régionale ou nationale. Par contre les voies de service sont cartographiée
avec une clé "service" ...


djakk

Le lun. 21 août 2017 à 01:28, Jérôme Amagat <jerome.ama...@gmail.com> a
écrit :

> Le 20 août 2017 à 15:22, djakk djakk <djakk.dj...@gmail.com> a écrit :
>
>> Cela dit, l'idéal serait de distinguer importance du réseau et type de
>> route : on pourrait avoir des "motorway primary" et des "motorway
>> secondary" (ou plutôt des "motorway trunk" et des "motorway primary"),
>> exemple avec l'A106 en région parisienne qui pourrait être qualifiée
>> d'autoroute secondaire.
>>
>
> oui pour moi c'est c'est un gros problème des tag highway=*, on mélange
> des choses différentes et donc après c'est difficiles de choisir le bon tag.
> motorway c'est un type de route on utilise ce tag en regardant son aspect
> et les règle qui s'y applique.
> primary, secondary, tertiary c'est en fonction de l'importance dans le
> réseau routier, en gros utiliser pour faire des grandes distances, des
> moyennes ou des plus courtes.
> Pour trunk, on c'est pas c'est quoi le critère, quand je lis çà : (
> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrunk) "highway=trunk
> for high performance roads that don't meet the requirement for motorway" je
> dirais qu'il faut choisir a la tête : si on y roule plus vite que sur
> d'autre type de route. Mais ici :
> https://wiki.openstreetmap.org/wiki/Key:highway on place trunk au dessus
> de primary et donc comme les routes les plus importantes du pays.
>
> D'ailleurs il y  a d'autres problèmes avec highway=*
> highway=residential, c'est juste une route en zone résidentiel (donc choix
> à la tête) ou c’est une route qui sert qu'aux résidents de la rue (et des
> quelques rue environnantes) (donc choix grâce à son utilisation)?
>
> highway=living_street, il faut utiliser ce tag suivant les règle qui s'y
> applique mais qu'est ce qu'on fait quand cette route est aussi un morceau
> de route du réseau tertiary, par exemple? highway=living_street;tertiary ?
>
> il y a aussi highway=path choisi à la tête et highway=footway et cycleway
> choisit en fonction des utilisateurs de la voie mais qui permet de supers
> combos footway avec bicycle=yes et cycleway avec foot=yes.
>
> ___
> 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] le festival de tout les highway :-)

[djakk djakk]

On aurait donc 5 clés différentes pour caractériser une route :
1) son importance (primaire, secondaire ...)
2) son classement administratif (panneau d'entrée ou de sortie d'autoroute
ou de "motorroad")
3) ses caractéristiques physiques (carrefours dénivelés, living_street,
route classique ...)
4) la largeur de ses voies (une route d'importance primaire peut être
étroite : exemple = Rennes - Angers autour de Martigné-Ferchaud)
5) la qualité de son revêtement (surtout utile dans les pays en voie de
développement)


djakk

Le lun. 21 août 2017 à 12:38, djakk djakk <djakk.dj...@gmail.com> a écrit :

> Alors je connais des "living_street" d'importance "primary" (Rennes, place
> de la République), ainsi que des "pedestrian" d'importance "primary" (la
> rue Le Bastard à Rennes) :-)
>
>
> djakk
>
> Le lun. 21 août 2017 à 12:06, marc marc <marc_marc_...@hotmail.com> a
> écrit :
>
>> En relisant, je trouve qu'il y a une assez grande cohérence puisque
>> hormis residential, les autres valeurs dépendent des panneaux routiers.
>>
>> Le 21. 08. 17 à 02:42, Jérôme Amagat a écrit :
>> > le panneau veux dire plusieurs choses sur son "aspect" minimum 2x2 voies
>> > séparées bandes d’arrêt d'urgence... et sur les règles a respecter, pas
>> > de velo, vitesse minimum, vitesse maximum plus élevé que sur les autres
>> > routes...
>>
>> Oui mais c'est inévitable. il n'y a aucune autoroute aménagée comme un
>> living_street et inversement.
>> alors oui fatalement autoroute implique à la fois l'importance de la
>> route (sa fonction première) et une série de valeur par défaut.
>> Vouloir séparer cela reviendrait à devoir mettre des milliers de tag de
>> valeur par défaut juste pour avoir un tag "purement" limité à
>> l'importance de la route, je ne vois pas ce qu'on gagnerait en pratique
>> malgré la "pureté" du critère. Et puis surtout comment pratiquement
>> évaluerais-tu ce critère d'importance de la route sans panneau ?
>>
>> Le 21. 08. 17 à 02:42, Jérôme Amagat a écrit :
>>  > Certaine route tertiaire sont plus proche en passant dessus d'une
>>  > autoroute que certaine route primaire.
>> l'autoroute Metz-Strasbourg est par endroit dans un état plus proche de
>> la route de compagne abandonnée que de l'autoroute. est-ce pour autant
>> que le classement est mauvais ? je trouve qu'il y a assez de clef pour
>> gérer les cas "tordu", ici en l’occurrence smoothness.
>> Dans ton exemple, la route tertiaire est peut-être mal classé. ou alors
>> c'est simplement parce que localement il y a des routes secondaires et
>> primaires plus importante. ou simplement l’age de la route.
>>
>> la seule chose qui me semble mériter réflexion, c'est le fait que des
>> nationales deviennent des départementales pour des raisons de
>> décentralisation et que du coup des départementale peuvent être ou pas
>> être en primary ou secondary, là le critère n'a pas été définit de
>> manière objective.
>> En Suisse par comparaison, c'est uniquement le panneau routier qui fait
>> la différence entre primaire, secondaire et tertiaire.
>>
>> Le 21. 08. 17 à 02:42, Jérôme Amagat a écrit :
>>  >>> Pour trunk, on c'est pas c'est quoi le critère
>>  >> c'est "quasi-autoroute" mais il manque souvent qlq détails à
>>  >> ces routes pour être des autoroutes, souvent entrée trop courte.
>>  > c'est quoi qui manque exactement
>> si tu connaissais la raison, que vas-tu en faire niveau osm ?
>> exemple : je connais des tunnels en ville 2x2 en trunk. La raison est
>> l'absence de bretelle d'entrée puisque le tunnel remonte parfois à la
>> surface pour être en contact avec une rue classique.
>> Je ne vois pas ce que tu voudrais faire niveau osm avec cette info.
>> Par contre l'avoir en trunk est utile, le routage devrait autant que
>> possible te faire utiliser le trunk et non pas les voies de classe
>> inférieur même si celle-ci font gagner quelques mètres sur le trajet.
>> ___
>> 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] le festival de tout les highway :-)

[djakk djakk]

Alors je connais des "living_street" d'importance "primary" (Rennes, place
de la République), ainsi que des "pedestrian" d'importance "primary" (la
rue Le Bastard à Rennes) :-)


djakk

Le lun. 21 août 2017 à 12:06, marc marc  a
écrit :

> En relisant, je trouve qu'il y a une assez grande cohérence puisque
> hormis residential, les autres valeurs dépendent des panneaux routiers.
>
> Le 21. 08. 17 à 02:42, Jérôme Amagat a écrit :
> > le panneau veux dire plusieurs choses sur son "aspect" minimum 2x2 voies
> > séparées bandes d’arrêt d'urgence... et sur les règles a respecter, pas
> > de velo, vitesse minimum, vitesse maximum plus élevé que sur les autres
> > routes...
>
> Oui mais c'est inévitable. il n'y a aucune autoroute aménagée comme un
> living_street et inversement.
> alors oui fatalement autoroute implique à la fois l'importance de la
> route (sa fonction première) et une série de valeur par défaut.
> Vouloir séparer cela reviendrait à devoir mettre des milliers de tag de
> valeur par défaut juste pour avoir un tag "purement" limité à
> l'importance de la route, je ne vois pas ce qu'on gagnerait en pratique
> malgré la "pureté" du critère. Et puis surtout comment pratiquement
> évaluerais-tu ce critère d'importance de la route sans panneau ?
>
> Le 21. 08. 17 à 02:42, Jérôme Amagat a écrit :
>  > Certaine route tertiaire sont plus proche en passant dessus d'une
>  > autoroute que certaine route primaire.
> l'autoroute Metz-Strasbourg est par endroit dans un état plus proche de
> la route de compagne abandonnée que de l'autoroute. est-ce pour autant
> que le classement est mauvais ? je trouve qu'il y a assez de clef pour
> gérer les cas "tordu", ici en l’occurrence smoothness.
> Dans ton exemple, la route tertiaire est peut-être mal classé. ou alors
> c'est simplement parce que localement il y a des routes secondaires et
> primaires plus importante. ou simplement l’age de la route.
>
> la seule chose qui me semble mériter réflexion, c'est le fait que des
> nationales deviennent des départementales pour des raisons de
> décentralisation et que du coup des départementale peuvent être ou pas
> être en primary ou secondary, là le critère n'a pas été définit de
> manière objective.
> En Suisse par comparaison, c'est uniquement le panneau routier qui fait
> la différence entre primaire, secondaire et tertiaire.
>
> Le 21. 08. 17 à 02:42, Jérôme Amagat a écrit :
>  >>> Pour trunk, on c'est pas c'est quoi le critère
>  >> c'est "quasi-autoroute" mais il manque souvent qlq détails à
>  >> ces routes pour être des autoroutes, souvent entrée trop courte.
>  > c'est quoi qui manque exactement
> si tu connaissais la raison, que vas-tu en faire niveau osm ?
> exemple : je connais des tunnels en ville 2x2 en trunk. La raison est
> l'absence de bretelle d'entrée puisque le tunnel remonte parfois à la
> surface pour être en contact avec une rue classique.
> Je ne vois pas ce que tu voudrais faire niveau osm avec cette info.
> Par contre l'avoir en trunk est utile, le routage devrait autant que
> possible te faire utiliser le trunk et non pas les voies de classe
> inférieur même si celle-ci font gagner quelques mètres sur le trajet.
> ___
> 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] contributions peut-être à revoir

[djakk djakk]

… et l'ambiguïté du "trunk" en France n'est pas résolue ^^

Cas compliqué transfrontalier : à une époque il aurait été intéressant
d'afficher sur osm "Lille - Rijsel" car "Rijsel" était la seule indication
de direction côté Belgique flamande sur les autoroutes :O

Perso dans le cas de l'occitan, je serais pour afficher les 2 noms
simultanément, après il faudrait utiliser non pas une clé name:langue
(impossible à gérer pour faire le rendu) mais une clé name_2 (voire aussi
une clé name_3), exemples :
• name=nom Français, name_2=nom occitan, affichage via mapnik : name +
(name_2) si name et name_2 sont différents
• name="Lille", name_2="Rijsel", affichage via mapnik "Lille (Rijsel)"

Mais alors comme "Paris" est fléché "Parijs" depuis la Belgique flamande,
faut-il avoir un name_2 = "Parijs" ? :-)


djakk

Le 27 août 2017 à 18:03, marc marc  a écrit :

> Le 27. 08. 17 à 17:21, Ch. Rogel a écrit :
> > Marc dit que les plaques bilingues officielles
> > pourraient être retranscrites
> non non j'ai dis exactement l'inverse !
> Je crains (= je suis contre) le jour où un petit village ou
> un individu change la plaque d'entrée d'un hameau, certains
> vont en déduire de la lecture du wiki qu'une photo de cette
> plaque serra la bénédiction nécessaire pour altérer le tag name.
>
> > Un seul endroit, en Europe, est une zone disputée à l'intérieur
> > d'un Etat, Bruxelles, mais le choc entre les "entités" fédérales
> > flamandes et wallonnes
> ben non :) Bruxelles et la Wallonie ne se superpose pas, ce sont
> des entités de même niveau. tu voulais sans doute dire la mal
> nommée fédération française" ou fédération Wallonie-Bruxeles
> En fait la décision de Bruxelles vient du fait que la zone est
> officiellement bilingue, les 2 noms ont la même légitimité.
> Je pense qu'il serrait prudent d'utiliser cette règle aussi.
> La France n'ayant aucune zone bilingue (aux grands regrets de certains),
> le seul nom "francophone" est l'officiel... sauf si un jour
> une commune change son nom pour avoir un autre nom officiel.
>
> Et pendant ce temps la moitié des adresses sont manquante...
> ___
> 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] contributions peut-être à revoir

[djakk djakk]

>
> Pour le rendu rien n’empêche un logiciel d'afficher les name:xx que l'on
> veut en plus du name=  il faut juste le faire..


C'est alors possible de faire une carte du monde en occitan, ou en
mandarin, mais pour faire une carte mondiale avec les noms officiels + les
noms en "patois" de chaque région du monde, le plus simple c'est d'avoir
une clé spéciale "name_2", sinon c'est très compliqué et peut être trop
coûteux en performance (il faudrait créer une carte des patois du monde et
l'intégrer dans la feuille de style mapnik). (Et encore, ça ne marcherait
pas pour Lille - Rijsel)


djakk

Le 27 août 2017 à 19:48, Bruno <pa...@free.fr> a écrit :

> Le 27/08/2017 à 18:58, djakk djakk a écrit :
>
> … et l'ambiguïté du "trunk" en France n'est pas résolue ^^
>
> Cas compliqué transfrontalier : à une époque il aurait été intéressant
> d'afficher sur osm "Lille - Rijsel" car "Rijsel" était la seule indication
> de direction côté Belgique flamande sur les autoroutes :O
>
> Perso dans le cas de l'occitan, je serais pour afficher les 2 noms
> simultanément, après il faudrait utiliser non pas une clé name:langue
> (impossible à gérer pour faire le rendu) mais une clé name_2 (voire aussi
> une clé name_3), exemples :
> • name=nom Français, name_2=nom occitan, affichage via mapnik : name +
> (name_2) si name et name_2 sont différents
> • name="Lille", name_2="Rijsel", affichage via mapnik "Lille (Rijsel)"
>
> Mais alors comme "Paris" est fléché "Parijs" depuis la Belgique flamande,
> faut-il avoir un name_2 = "Parijs" ? :-)
>
>
> On ne tague pas pour le rendu ;-)
> Ce que tu décris doit être géré par les logiciels de routage , pas par la
> carte , ça serait illisible , même si on ne tague pas pour le rendu..
> Le logiciel de routage sait que tu es en Flandre et t'indique la direction
> avec la langue de cette région : "prenez la direction de Rijsel" et il
> trouve ça dans la base avec le champ name:nl
>
> Pour le cas de l'Occitan, mettre les deux noms dans le name= reviendrait à
> dire que les deux langues sont officielles, ce qui est faux.
> Pour le rendu rien n’empêche un logiciel d'afficher les name:xx que l'on
> veut en plus du name=  il faut juste le faire..
>
>
>
> djakk
>
> Le 27 août 2017 à 18:03, marc marc <marc_marc_...@hotmail.com> a écrit :
>
>> Le 27. 08. 17 à 17:21, Ch. Rogel a écrit :
>> > Marc dit que les plaques bilingues officielles
>> > pourraient être retranscrites
>> non non j'ai dis exactement l'inverse !
>> Je crains (= je suis contre) le jour où un petit village ou
>> un individu change la plaque d'entrée d'un hameau, certains
>> vont en déduire de la lecture du wiki qu'une photo de cette
>> plaque serra la bénédiction nécessaire pour altérer le tag name.
>>
>> > Un seul endroit, en Europe, est une zone disputée à l'intérieur
>> > d'un Etat, Bruxelles, mais le choc entre les "entités" fédérales
>> > flamandes et wallonnes
>> ben non :) Bruxelles et la Wallonie ne se superpose pas, ce sont
>> des entités de même niveau. tu voulais sans doute dire la mal
>> nommée fédération française" ou fédération Wallonie-Bruxeles
>> En fait la décision de Bruxelles vient du fait que la zone est
>> officiellement bilingue, les 2 noms ont la même légitimité.
>> Je pense qu'il serrait prudent d'utiliser cette règle aussi.
>> La France n'ayant aucune zone bilingue (aux grands regrets de certains),
>> le seul nom "francophone" est l'officiel... sauf si un jour
>> une commune change son nom pour avoir un autre nom officiel.
>>
>> Et pendant ce temps la moitié des adresses sont manquante...
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> 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] contributions peut-être à revoir

[djakk djakk]

Je ne suis pas fan des sources officielles, bon dans la majorité des cas ça
coïncide avec l'usage, mais j'ai 2 contre-exemples :
• Saint-Quentin-en-Yvelines n'est plus officiellement une ville nouvelle
(?), mais reste représentée par le nom de l'université, ou par le nom de la
gare … est-ce que dans l'usage on utilise
encore Saint-Quentin-en-Yvelines ? Si oui, il faudrait un nœud "place=city"
pour la ville non-officielle de Saint-Quentin-en-Yvelines
• Cherbourg-Octeville : je ne sais pas où ça en est, je suppose que le nom
officiel est passé Cherbourg-Octeville, mais on utilise Cherbourg y compris
sur les panneaux de signalisation directionnelle verts et je suppose que
l'usage a toujours été "Cherbourg"

Le 28 août 2017 à 12:54, Christian Quest  a écrit :

> Principe cardinal: représenter ce qu'il y a sur le terrain ? Oui, mais
> avec intelligence...
>
> Le gros avantage d'OSM c'est de permettre de mettre les noms en autant de
> langues que l'on veut avec name:xx=* et en même temps de préciser la langue
> en question, ce qu'un panneau ou une plaque dans la rue ne peut pas
> préciser.
>
> Ceci permet aussi au réutilisateur des données de faire son choix dans les
> langues qu'il veut mettre en avant (le rendu FR utilisera par exemple
> name:fr en priorité).
>
> Pour le name=*, la convention sur OSM c'est de mettre la langue officielle
> du pays, donc en France le français (ou autre si il n'y a pas de version du
> nom en français).
>
> Il y a des exceptions à cette règle pour les pays/régions/communes
> multilingues: Bruxelles, mais aussi la Suisse... qui compte 4 langues
> officielles. Là pour ne pas favoriser une langue par rapport à d'autres, on
> les met toutes.
>
>
> A minima, en France pour les noms de commune, on est quand même bien
> d'accord que name=* correspond au nom du Code Officiel Géographique de
> l'INSEE.
>
>
>
> Le 28/08/2017 à 11:50, Christian Rogel a écrit :
>
>> Le 28 août 2017 à 07:53, Bruno  a écrit :
>>>
>>> Le 27/08/2017 à 22:05, Christian Rogel a écrit :
>>>
 Le 27 août 2017 à 17:04, Bruno  a écrit :
>
 En gros, il y a un conflit théorique entre deux sources de légitimité :
 ce qu'on voit et ce que l'autorité compétente a voulu signifier.

>>> Pour moi aucune complexité,
>>> Il me semble que l'on voit sur la plaque le nom d'une rue dans deux
>>> langues  , il n'y a pas de conflit.
>>> Le champ name contient le nom dans une langue , et name:xx dans une
>>> autre, c'est fait pour ça.
>>>
>> C'est pourtant contraire à un principe cardinal d'OSM : représenter ce
>> qu'il sur le terrain.
>> L'exemple bruxellois montre qu'on peut faire autrement tout en donnant
>> leur place aux suffixes de langue.
>> Même si un nombre infinitésimal de communes a choisi de placer les deux
>> noms  sur un même niveau juridique, l'effacer dans la représentation du
>> terrain est une voie de fait, puisque c'est nier la décision d'un corps élu.
>>
>> Si il pouvait y avoir conflit c'est sur le choix de la langue dans l'un
>>> ou l'autre champ , mais en France il n'y a pas d'ambiguité, pas de
>>> bilinguisme en métropole.
>>>
>>
>> Là, tu introduis un argument non plus technique, mais politique, donc
>> renversable par nature. Pas de question de bilinguisme en jeu, il suffirait
>> que le Parlement prescrive qu'aucun élément d'une plaque de rue ne soit
>> laissé de côté.
>>
>> Christian R.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> 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] harmonisation tag network Arc-en-ciel dans le département du Nord région Hauts-de-France

[djakk djakk]

Salut, je suis contre ajouter le suffixe "(Nord)" au nom du réseau. C'est
comme le nom d'une rue, le même nom peut exister dans plusieurs communes.

Le 25 août 2017 à 14:57,  a écrit :

> Contre, pour les raisons évoquées par Noémie.
>
> Mais homogénéiser c'est bien. Pourquoi ne pas mettre "Réseau Arc-en-Ciel"
> en HG puisque c'est ce qui est écrit sur les bus, si on tient vraiment à
> l'unicité ? Mais ça ce sont aux locaux de le dire.
>
> Avec l'identifiant Wikidata on la possibilité d'identifier les deux
> réseaux. Une simple comparaison de la latitude devrait d'ailleurs suffire.
> Pas exactement un calcul compliqué.
>
> Pour moi ce lien permet de faire un contrôle qualité, ni plus ni moins.
>
> Pour moi la tag Wikidata c'est une référence, pas un contenu : pour moi
> c'est un peu de l'intégration, pas de l'importation. Qui permet de suivre
> facilement ce que ceux qui travaillent sur Wikipedia disent (rappel : pour
> la fusion des communes ils sont souvent plus à jour que nous).
>
> Des gens travaillent sur Wikipédia, des gens travaillent sur OSM.
>
> Je ne vois pas de problème à ce que l'on bénéficie de l'information qu'un
> réseau a changé de nom parce que quelqu'un a mis à jour une page Wikipédia.
> Ça ne veut pas dire que la modif soit à reporter. Des erreurs il y en a
> partout.
>
> Alors si OSM permet d'améliorer Wikipédia et Wikipédia OSM, ça ne me
> dérange pas.
>
> Par contre si l'un dégrade l'autre je suis contre.
>
> Par exemple Lenny dit "la ligne 25 a été supprimé il y a pas mal de temps"
> Et alors ? Si on regarde l'article Wikipédia
>   en
> question il n'a pas de ligne 25. Et il me semble assez détaillé. A-t-on de
> meilleurs infos de moins bonnes info dans OSM ? Ne peut-on profiter l'un de
> l'autre ?
>
> On sait que les mises à jour des catégories merdent sur le wikimedia et il
> est bien écrit "Wikimedia list article" sur le Q3250969
> . Et "Wikinews article" sur
> l'autre. Il est donc possible de filtrer pour trouver ce qui nous intéresse.
>
> Un article sur la création d'une ligne : soit WikiNews t'intéresse soit
> WikiNews ne t'intéresse pas.
>
> Et alors ?
>
> Si par là tu veux dire que tu ne veux pas chercher le wikidata depuis la
> liste wikidata, OK, pourquoi ne pas partir de Wikipédia et cliquer sur
> élément Wikidata.
>
> Je pense que ce qui nous manque ce sont les outils pour gérer les
> wikidata, ça semble un fatras à première vue.
>
> Voici ce que je disais tantôt à Jo, ça devrait rassurer sur le fait que
> j'ai un œil critique sur les Wikidata.
>
> *Je connais pire dans le genre : un film culte (Plogoff : des Pierres
> contre des Fusils) supprimé par un vote d'administrateurs pronucléaires.
> Ils s'étaient coordonnés et avaient fait un vote rapide. Pas de notoriété
> suffisante.*
> * On les a pris en flagrant délit : la page sur EPR disait que le
> rendement était de 20 % meilleur (non-dit : du fait d'un meilleur taux de
> combustion càd combustible plus enrichi laissé plus longtemps dans le
> réacteur, combustible HTC).*
> * Alors je prends soin de citer un texte de Poviisa (organisme dépendant
> des exploitants nucléaires et chargé du centre d'enfouissement finlandais)
> : 7 fois plus de rejets  gazeux.*
>
> * Rejet d'un pronucléaire au prétexte que c'était spécifique au HTC et non
> à l'EPR et que je devais créer une page spécifique sur le HTC pour mettre
> ces informations.*
> * Avec cette logique il aurait dû supprimer le paragraphe sur les 20 %,
> j'ai d'ailleurs failli le faire.*
>
> * Je parle de ça à un antinucléaire. Il m'apprend qu'il avait voulu faire
> une page sur le HTC et cette même personne avait retoqué la page pour cause
> de manque de notoriété.*
>
> * Mais ceci est bien loin de notre sujet de départ.*
>
> Quant à l'unicité, si un réseau n'est pas dans Wikipédia, cj n'imagine pas
> qu'il soit de grande étendue et recouvrant un réseau de même nom.
> Sur le contrôle de complétude, idem (avec le bon point relevé par Vincent
> je crois sur l'affichage direct dans OSM).
>
> Et sur le network:wikidata=Oxxx c'était une c... sauf à préciser que si
> c'est en O, les règles de QA à appliquer se font par rapport à un wiki OSM
> (par exemple). Permet de régler le problème de notoriété. Sinon en bonne
> intelligence demander à Wiki* d'accepter que les ajouts référencés par OSM
> soient suffisants pour que la donnée reste dans OSM.
>
> Pour mettre deux conditions dans Overpass, pas la peine de coder,
> l'assistant suffit :
>
> shop=seafood and name="Le Terre-Neuvas" in guidel”
> 
>
> Pas une ligne de code de tapée.
>
> And=et, in=dans.
>
> Je dis ça pour Lenny : là ce sont des mots courants, donc sans doute pas
> de problème, mais tu dois le dire clairement "pas d'anglais SVP" (.
>
> Ne pas parler anglais n'est pas un problème c'est un handicap. Et comme
> pour beaucoup de handicaps le problème 

Re: [OSM-talk-fr] Trunk

[djakk djakk]

Merci Christian, effectivement on aurait besoin d'un niveau de plus pour
avoir une hiérarchisation plus fine. Et le classement du réseau breton en
"autoroute osm", j'approuve !


djakk

Le dim. 20 août 2017 à 13:36, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

>
> Le 2017 Eost 18 à 12:20, djakk djakk <djakk.dj...@gmail.com> a écrit :
>
> Salut,
>
> Je reviens sur ce sujet épineux qu'est la classification "trunk".
>
> Moi je serai pour utiliser la définition anglaise et japonaise (un niveau
> de classification de route parmi les autres, au-dessus de primary).
> Par exemple l'axe est-ouest N175-N176-E401 du côté de Saint-Malo serait
> intégralement en "trunk" malgré les traversées de villages et les portions
> à 2*2 voies pas aux normes (pas de bande d'arrêt d'urgence, pas de
> classification "route pour automobiles" donc ouvert aux vélos et aux
> piétons).
>
> Sinon "trunk" serait réservé aux 2*2 voies, dénivelées ou non (car même si
> c'est non dénivelé, ouvert aux véhicules agricoles et aux vélos la
> limitation par défaut d'une 2*2 voies est 110km/h).
>
> Je ne vois pas de 3e option.
>
> But du jeu = mettre à jour le Wiki qui est contradictoire ;)
>
>
> Ayant déjà soulevé cette question, je rappelle ma vision du problème :
>
>- dans la mesure où la réglementation évolue, soit vers une
>différenciation (voie rapide vs boulevard urbain, abaissement pour certains
>axes), il est de plus plus incohérent de faire de la vitesse autorisée un
>critère pour juger des qualités des routes. Cela paraît même un peu « old
>school »
>- La question est autant de pouvoir surclasser certaines « primary »
>que de cesser de coller sans réflexion au schéma mental des fonctionnaires
>de l’Équipement qui n’ont pasque des critères routiers, quand ils
>différencient (et l’IGN les suit, bien sûr) les voies express des
>autoroutes, alors que l’expérience conducteur le dément
>- On peut, soit reclasser comme « motorway » certaines liaisons 2 x 2
>(réseau breton, charentais, N 4, etc.), soit les classer classer
>« motorroad » l(est-il normal que nous n’utilisions pas cet attribut ?)
>- Décaler la qualification des niveaux supérieurs donnerait des marges
>pour hiérarchiser plus finement les autres voies
>
>
>
> Christian R.
> ___
> 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] le festival de tout les highway :-)

[djakk djakk]

Alors une route primaire en même temps living_street c'est simple, tu mets
ce panneau carré bleu avec des piétons et une "limitation à 20 km/h"
incrusté (
https://fr.m.wikipedia.org/wiki/Panneau_de_signalisation_d%27une_zone_de_rencontre_en_France)
sur un des axes les plus importants d'une ville (quoiqu'en dise Philippe,
j'ai fait un petit sondage sur la mailing-list bzh c'est un axe "secondary"
au minimum). ;-)


djakk

Le lun. 21 août 2017 à 19:59, marc marc <marc_marc_...@hotmail.com> a
écrit :

> Le 21. 08. 17 à 12:38, djakk djakk a écrit :
> > je connais des "living_street" d'importance "primary" (Rennes,
> > place de la République), ainsi que des "pedestrian" d'importance
> > "primary" (la rue Le Bastard à Rennes) :-)
> c'est à mes yeux tellement incohérent que je n'arrive même à imaginer ce
> que tu veux dire.
> primary = route donc la fonction première est d’assurer le trafic de
> transit entre des lieux/routes importants.
> living_street = route dont la fonction est d'être un espace de vie
> piéton et où l'automobile est toléré et subalterne au piéton.
>
> Je ne vois pas comment un même lieu peux être les 2 à la fois.
>
> Le 21. 08. 17 à 12:46, djakk djakk a écrit :
>  > 1) son importance (primaire, secondaire ...)
>  > 2) son classement administratif (panneau d'entrée ou de sortie
>  > d'autoroute ou de "motorroad")
>  > 3) ses caractéristiques physiques (carrefours dénivelés,
>  > living_street, route classique ...)
> panneau/utilité/aménagement sont 3 faces d'une même pièce même s'il y a
> des variations sur les détails.
>
>  > 5) la qualité de son revêtement (surtout utile dans les pays
>  > en voie de développement)
> et aux mobilités alternatives. le vélo de vile ou le roller sur une
> route dégradée, c'est inconfortable.
> ___
> 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] le festival de tout les highway :-)

[djakk djakk]

Discussion sur le changeset :
https://www.openstreetmap.org/changeset/44756436

Oui le "living_street" est bizarre au milieu de la "primary" mais c'est
comme ça …

Le 31 août 2017 à 13:43, marc marc <marc_marc_...@hotmail.com> a écrit :

> Dommage pour le ping pong de changeset entre djakk et Philippe
> Dommage aussi d'avoir un primary qui ne mène nulle-part en pleine ville
> une route tertiaire aurait vraiment été un compromis minimaliste
> avec une source et une note qui décrit pourquoi la valeur a été choisie
> s'il y a un supposé conflit entre les panneaux et.. jenesaisquoi
>
> Le 30. 08. 17 à 22:23, Romain MEHUT a écrit :
> > Ce sujet avait été discuté sur la liste bretonne en mai cf.
> > https://lists.openstreetmap.org/pipermail/talk-fr-bzh/
> 2017-May/002021.html
> > et les Rennais ne sont pas prompts à passer à living_street.
> >
> > Le 22 août 2017 à 15:33, marc marc a écrit :
> >
> > Le 21. 08. 17 à 21:35, djakk djakk a écrit :
> >  > une route primaire en même temps living_street c'est simple, tu
> >  > mets ce panneau carré bleu avec des piétons et une "limitation à
> 20
> >  > km/h" incrusté sur un des axes les plus importants d'une ville
> > Si rien d'autre n'a été fait, c'est 0/20 pour le responsable de
> > l'aménagement mais niveau osm c'est à mon avis limpide :
> >
> > La route/zone couverte par le panneau living_street est uniquement
> > living_street car la priorité est le piéton, il peux circuler sur cet
> > espace comme bon lui semble, jouer au ballon, faire son lacet où bon
> lui
> > semble, même sans aménagement agréable, cet espace a perdu sa
> vocation
> > prioritaire au transit.
> >
> > Le bout de route avant et après cette zone à mes yeux devrait lui
> aussi
> > être rétrogradé de primaire à au maximum tertiaire voir résidentiel
> au
> > moins jusqu'au gros carrefour précédent et suivant.
> >
> > Après que le routage ou les habitués décident de passer avec un 40T
> > parce qu'il gagne 2 min ou simplement parce que "c'était comme cela
> > avant", à mon avis ce n'est pas cela qui change la situation.
> > Si le trafic de transit utilise réellement toujours ce trajet, je
> pense
> > qu'il y aussi un 0/20 pour la signalisation au carrefour précédent et
> > pour la non-maj des gps éventuellement utilisé par les non-locaux.
> >
> > Ce n'est bien sur que mon avis et je sais que les gens détestent les
> > changements administratifs si cela ne leur conviennent pas.
> > Mais l'unique autre solution c'est de tager dans osm selon son envie
> > subjective de à quoi devrait servir la route en ignorant les
> panneaux,
> > Cela me semble conduire vers des données moins utilisable puisque le
> > routage va envoyer un 40T en transit sur une route inadaptée.
> > Si la communauté locale ne veux pas de la maj, ce n'est pas moi qui
> irai
> > la faire, je suis pour les compromis autant que possible :-)
> > Je pense cependant que cela mérite réflexion "locale" pour faire la
> part
> > entre nostalgie et situation réelle.
> > Cela mérite aussi un message à l'administration s'il y a des
> problèmes
> > de qualité (aménagement, signalisation)
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
> > https://lists.openstreetmap.org/listinfo/talk-fr
> > <https://lists.openstreetmap.org/listinfo/talk-fr>
> >
> >
> >
> >
> > ___
> > 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] le festival de tout les highway :-)

[djakk djakk]

Il faudrait un highway=primary + living_street=yes ou
highway=primary_living_street :)

Le 31 août 2017 à 17:36, Jérôme Amagat <jerome.ama...@gmail.com> a écrit :

> on a d'autres cas (surtout sur des tertiary) qui provoquent des
> signalements sur osmose "continuité rompue des highways" :
> http://osmose.openstreetmap.fr/fr/map/#item=1120
>
> "Oui le "living_street" est bizarre au milieu de la "primary" mais c'est
> comme ça …"
>
> si living_street et primary sont juste tous les 2, pourquoi privilégier
> living_street ? :)
>
> Et osm n'est pas là pour faire le travail de la commune (diminuer le
> trafic dans une rue du centre ville) si l'usage c'est que c'est toujours la
> route utilisée pour traverser la ville, la route fait toujours partie du
> réseau primaire (ou secondaire ou tertiaire suivant les cas)
>
>
>
> Le 31 août 2017 à 16:05, djakk djakk <djakk.dj...@gmail.com> a écrit :
>
>> Discussion sur le changeset : https://www.openstreetmap.org/
>> changeset/44756436
>>
>> Oui le "living_street" est bizarre au milieu de la "primary" mais c'est
>> comme ça …
>>
>> Le 31 août 2017 à 13:43, marc marc <marc_marc_...@hotmail.com> a écrit :
>>
>>> Dommage pour le ping pong de changeset entre djakk et Philippe
>>> Dommage aussi d'avoir un primary qui ne mène nulle-part en pleine ville
>>> une route tertiaire aurait vraiment été un compromis minimaliste
>>> avec une source et une note qui décrit pourquoi la valeur a été choisie
>>> s'il y a un supposé conflit entre les panneaux et.. jenesaisquoi
>>>
>>> Le 30. 08. 17 à 22:23, Romain MEHUT a écrit :
>>> > Ce sujet avait été discuté sur la liste bretonne en mai cf.
>>> > https://lists.openstreetmap.org/pipermail/talk-fr-bzh/2017-M
>>> ay/002021.html
>>> > et les Rennais ne sont pas prompts à passer à living_street.
>>> >
>>> > Le 22 août 2017 à 15:33, marc marc a écrit :
>>> >
>>> > Le 21. 08. 17 à 21:35, djakk djakk a écrit :
>>> >  > une route primaire en même temps living_street c'est simple, tu
>>> >  > mets ce panneau carré bleu avec des piétons et une "limitation
>>> à 20
>>> >  > km/h" incrusté sur un des axes les plus importants d'une ville
>>> > Si rien d'autre n'a été fait, c'est 0/20 pour le responsable de
>>> > l'aménagement mais niveau osm c'est à mon avis limpide :
>>> >
>>> > La route/zone couverte par le panneau living_street est uniquement
>>> > living_street car la priorité est le piéton, il peux circuler sur
>>> cet
>>> > espace comme bon lui semble, jouer au ballon, faire son lacet où
>>> bon lui
>>> > semble, même sans aménagement agréable, cet espace a perdu sa
>>> vocation
>>> > prioritaire au transit.
>>> >
>>> > Le bout de route avant et après cette zone à mes yeux devrait lui
>>> aussi
>>> > être rétrogradé de primaire à au maximum tertiaire voir
>>> résidentiel au
>>> > moins jusqu'au gros carrefour précédent et suivant.
>>> >
>>> > Après que le routage ou les habitués décident de passer avec un 40T
>>> > parce qu'il gagne 2 min ou simplement parce que "c'était comme cela
>>> > avant", à mon avis ce n'est pas cela qui change la situation.
>>> > Si le trafic de transit utilise réellement toujours ce trajet, je
>>> pense
>>> > qu'il y aussi un 0/20 pour la signalisation au carrefour précédent
>>> et
>>> > pour la non-maj des gps éventuellement utilisé par les non-locaux.
>>> >
>>> > Ce n'est bien sur que mon avis et je sais que les gens détestent
>>> les
>>> > changements administratifs si cela ne leur conviennent pas.
>>> > Mais l'unique autre solution c'est de tager dans osm selon son
>>> envie
>>> > subjective de à quoi devrait servir la route en ignorant les
>>> panneaux,
>>> > Cela me semble conduire vers des données moins utilisable puisque
>>> le
>>> > routage va envoyer un 40T en transit sur une route inadaptée.
>>> > Si la communauté locale ne veux pas de la maj, ce n'est pas moi
>>> qui irai
>>> > la faire, je suis pour les compromis autant que possible :-)
>>> > Je pense cependant que cela mér

Re: [OSM-talk-fr] Projet du mois : suppression des landuse=industrial; retail

[djakk djakk]

Salut,

le truc c'est que les zones voulues 100% industrielles au départ sont
devenues au fil du temps à moitié industrielles à moitié retail voire une
troisième moitié en zone à bureaux :), exemple à Rennes :
https://www.openstreetmap.org/#map=18/48.10399/-1.73425
Comment cartographier ces zones (globalement, sans aller jusqu'au détail
parcelle par parcelle) ? landuse=industrial;retail;commercial me vient en
premier lieu mais je trouve le ";" moche ; landuse=
industrial_and_retail_and_commercial ?


djakk

Le 1 septembre 2017 à 00:26, Jérôme Amagat  a
écrit :

> Je vais y aller de mon idée de projet du mois, moi aussi :)
>
> On a d’après taginfo (https://taginfo.openstreetmap.fr/tags/landuse=
> industrial%3Bretail#overview) :
> 544  landuse=industrial;retail qui viennent pour la plupart de l'import
> des données CORINE Land Cover, import qui date de 2009.
> landuse=industrial;retail ça veux rien dire, beaucoup on disparu avec le
> temps mais ça serai bien de finir de les supprimer 8 ans après leur import.
>
> C'est un projet où tout le monde peut participé, on peut trouvé les lieu
> où ce tag existe avec overpass :
> http://overpass-turbo.eu/s/ros
> Après, grâce aux photos aériennes et aux informations déjà pressentent
> dans osm (nom d'entreprise, shop, centre commerciaux...) , il est assez
> simple de repérer si l'on a affaire à une zone industrielle, de bureau ou
> de commerce (landuse=industral, commercial ou retail) voir résidentiel.
> Il faut souvent améliorer le tracé du polygone voir le découper en
> plusieurs zones (industriel , de commerce ...)
> On peut en profiter pour supprimer les tags CLC:code=*, CLC:id=*,
> CLC:year=* inutiles ainsi que "note=CLC import: update the tag landuse with
> either industrial or retail after survey"
> et "note:fr=Import CLC: ajustez le tag landuse avec soit industrial, soit
> retail après contrôle" voir même le tag "source=Union européenne - SOeS,
> CORINE Land Cover, 2006." surtout si l'on modifie la géométrie en plus du
> tag landuse=*.
>
> Projet du mois ou pas, ce message permet de rappeler que
> landuse=industrial;retail n’était pas fait pour durer comme il est écrit
> dans les "note:fr=Import CLC: ajustez le tag landuse avec soit industrial,
> soit retail après contrôle" importé avec eux il y a plusieurs années. et
> donc si des gens ont du temps a perdre :) il y a ces polygones à
> supprimer/modifier et en même temps si le coin vous plaît vous pouvait
> améliorer les alentours :) .
>
> ___
> 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] contributions peut-être à revoir

[djakk djakk]

>
> Encore une fois on part d'un sujet (le multilinguisme dans les name) et on
> dérive (ici sur les noms historiques).


C'était pour dire "attention aux sources officielles" :)


Le 28 août 2017 à 22:21,  a écrit :

> Encore une fois on part d'un sujet (le multilinguisme dans les name) et on
> dérive (ici sur les noms historiques).
>
> Tu voulais parler de Cherbourg-en-Cotentin
> ,
> comme dit Wikipédia :
>
> *Cherbourg-en-Cotentin** est une commune du nord du département de la **Manche
> **. Elle est
> créée officiellement le **1er** janvier 2016**2
> **,
> par la réunion des cinq communes membres de la **communauté urbaine de
> Cherbourg
> **
> sous le statut de **commune nouvelle
> ** : **Cherbourg-Octeville
> ** (elle-même issue de
> la fusion des communes de Cherbourg et **Octeville
> ** le **1er** mars
> 2000), **Équeurdreville-Hainneville
> ** (issue
> de la fusion des communes d'**Équeurdreville
> ** et **Hainneville
> ** en 1965), **La
> Glacerie **, **Querqueville
> ** et **Tourlaville
> **.*
>
> Je vois que l'admin_centre a pour name Cherbourg.
>
> Cherbourg, c'est le nom court de Cherbourg-en-Cotentin et aussi la ville
> initiale.
>
> À Brest il y a Brest la ville regroupant Brest, Saint-Pierre-Quilbignon,
> Lambézellec et Saint-Marc. Pour parler du centre (la ville d'origine), les
> Brestois parlent de Brest-même, c'est un loc_name.
> Et je ne vois pas le rapport avec le multilinguisme.
>
> Certains pays du Maghreb ont aussi des traditions similaires aux pays
> multilingues européens : plusieurs noms dans le name.
> https://wiki.openstreetmap.org/wiki/Proposed_features/Language_information_for_name
> a été rejeté mais ne prévoyait explicitement pas les noms multilingues
> (voir discussion).
>
> Séverin, si tu fais des formation, et que tu ne cites pas talk-fr, les
> gens vont dire qu'il faut une liste sur les attributs. Ça ne veut pas dire
> que talk-fr ne leur conviendrait pas. Et en "déduire" que la faible
> fréquentation de [talk-fr] en est la preuve me semble plus un renversement
> de preuve.
> En particulier sur le multilinguisme ne pas avoir que le point de vue
> jacobin aide.
>
> Saint-Quentin-en-Yvelines semble exister en tant que Communauté
> d'agglomération de Saint-Quentin-en-Yvelines
>   et a
> bien son alt_name.
>
> Le 28 août 2017 à 12:54, Christian Quest  a
> écrit :
> *Principe cardinal: représenter ce qu'il y a sur le terrain ? Oui, mais
> avec intelligence...*
>
> * Le gros avantage d'OSM c'est de permettre de mettre les noms en autant
> de langues que l'on veut avec name:xx=* et en même temps de préciser la
> langue en question, ce qu'un panneau ou une plaque dans la rue ne peut pas
> préciser.*
>
> Ce résumé me plait bien. Et je pense plus utile de travailler sur la
> représentation. Par exemple les panneaux routiers dans la Bretagne
> brittophone sont ne général bilingues. Avoir un itinéraire en breton est
> équivalent à un itinéraire en français.
>
> *A minima, en France pour les noms de commune, on est quand même bien
> d'accord que name=* correspond au nom du Code Officiel Géographique de
> l'INSEE.*
> Au niveau des lieux-dits, c'est déjà plus flou.
> J'ai par exemple "corrigé" un "La Mort Anglaise" en "Ar Beg Bereneg" et
> mis le "La Mort Anglaise" en alt_name.
> Car si les deux se disent en français, c'est Ar Beg Bereneg qui est écrit
> sur les panneaux routiers (par contre à côté Trez-Rouz conserve son nom -
> d'où la remarque de Christian R., à ce niveau là les noms sont en général
> en breton). Il n'est pas impossible ce que soit pour ne pas fâcher les
> touristes anglais : les deux font allusion à une bataille perdue par les
> Anglais, le second nom (la plage rouge) n'étant pas comprise par les
> anglais ou les français sans explication : c'est la couleur du sable après
> l'hécatombe).
> Le fait est que j'ai deux sources l'une disant "La Mort Anglaise"
> (FANTOIR) l'autre "Ar Beg Bereneg" (les panneaux routiers) ou "Bereneg" et
> du coup je me demande ce qui est name et ce qui est alt_name. loc_name
> c'est Bereneg (ou Berenec : le son en breton est entre le G et le C, les
> Français ont souvent changé des eg en ec).
> 

Re: [OSM-talk-fr] Marne la Vallée

[djakk djakk]

Bonne question ! J'ai la même question avec les noms des vallées ou des
"petits pays" style le Vercors, le cap Sizun ou le Trégor

Le 30 novembre 2017 à 23:42, Philippe Verdy  a écrit :

>
>
> Le 30 novembre 2017 à 21:16,  a écrit :
>
>> Comme tu dis, 7 c'est arrondissement et donc pas machin. Il y a une
>> sous-préfecture à Torcy, commune de Marne-la-Vallée.
>> L'arrondissement de Torcy
>>  ne recouvre pas
>> le machin de Marne-l'Avalée.
>>
>> boundary=place de Christian, à la EPCI comme suggère vdct ou place= sur
>> un node si on veut juste que Nominatim trouve ça.
>> N.B. : la graphie de Marne-la-Vallée est compatible avec celle d'une
>> commune, il n'y a pas d'espaces dans le nom.
>>
>> Et au fait pour le Rhône, on a bien 2 admin_level=6 :
>> - Métropole de Lyon 
>> - Rhône 
>>
>> Qui ensemble constituent la Circonscription départementale du Rhône
>>  qui comme son nom ne
>> l'indique pas est de niveau 5 et a le rôle d'une préfecture.
>> Or là on viole la règle de pavage d'un niveau admin 4 en zones de niveau
>> 5.
>>
> Il n'y a pas violation: dans tous les départements sauf le Rhône la zone
> de niveau 5 (préfecture de département) correspond à la même zone de niveau
> 6 (conseil départemental). On a bien un pavage complet au niveau 5 en
> mettant au même niveau toutes les préfectures de département. Il est
> complet aussi au niveau 6 (tous les départements et la métropole de Lyon).
>
> Le tout reste hiérarchique, mais on n'a pas eu besoin de dupliquer presque
> toutes les 100 relations de niveau 6 (sauf une) vers le niveau 5. comparez
> avec le découpage de l'Allemagne ou une même subdivision cumule les
> compétences de plusieurs niveaux ailleurs (d'où des pseudo-"trous" par
> exemple au niveau 8 pour les communes qui sont modélisées par une seule
> entité à un des autres niveaux de compétence).
> Ce qu'on n'a pas dans admin_level c'est la possibilité de mettre plusieurs
> valeurs: une valeur unique a été choisie arbitrairement (le niveau le plus
> prévalent en terme de compétences : en Allemagne c'est le niveau du Land
> qui prévaut à cause du régime fédéral et du fonctionnement de la
> législation et des constitutions locales).
>
> Il n'y a d'ailleurs aucune obligation à tout découper jusqu'à des niveaux
> élevés identiques partout : l'arbre peut avoir des branches plus hautes que
> d'autres, et même parfois des branches qui se recoupent partiellement
> (comme en Espagne avec les comarques qui ne suivent pas partout le
> découpage provincial de l'Etat).
>
> ___
> 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

[OSM-talk-fr] Circulation à gauche (en France)

[djakk djakk]

Bonjour ! Comment tagger une rue à double-sens dont la circulation
s’effectue à gauche ?

Exemple : Tulle, rue Jean Mermoz


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

[OSM-talk-fr] Zone 30 km/h

[djakk djakk]

Salut !

Polygone ou trait par trait pour les zones limitées à 30 km/h ? ;)

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

Re: [OSM-talk-fr] Circulation à gauche (en France)

[djakk djakk]

D’après Google street view, il y a un séparateur central avec une longue
interruption au niveau de l’entrée du parking. (Google, donc ne pas copier
!)


djakk

Le lun. 25 juin 2018 à 16:34, Dominique Rousseau  a
écrit :

> Le Mon, Jun 25, 2018 at 04:12:42PM +0200, Francescu GAROBY [
> windu...@gmail.com] a écrit:
> > Bonjour,
> > La rue a-t-elle un séparateur central, pour éviter que les gens roulent
> du
> > mauvais côté (à droite) par habitude ? Si oui, peut-être que faire 2
> ways à
> > sens unique serait la solution ?
>
> La photo aerienne ne semble pas montrer de separation.
> Mais moi, je fairais ca avec 2 way a sens unique, pour eviter toute
> ambiguite dans un moteur de routage.
> (c'est curieux comme disposition, mais a voir l'emplacement de la rue
> entre 2 rues a sens uniques, c'est assez logique)
>
>
> >
> > Francescu
> >
> > Le 25 juin 2018 à 15:55, djakk djakk  a écrit :
> >
> > > Bonjour ! Comment tagger une rue à double-sens dont la circulation
> > > s???effectue à gauche ?
> > >
> > > Exemple : Tulle, rue Jean Mermoz
> > >
> > >
> > > Julien « djakk »
> > >
> > > ___
> > > Talk-fr mailing list
> > > Talk-fr@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-fr
> > >
> > >
> >
> >
> > --
> > Francescu
>
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
>
>
> --
> Dominique Rousseau
> d...@lee-loo.net - 06 82 43 12 27
>
> A l'instant où l'esclave décide qu'il ne sera plus esclave,
> ses chaînes tombent.  -- Mahatma Gandhi
>
> ___
> 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

[OSM-talk-fr] Limitation de vitesse par défaut

[djakk djakk]

Bonjour !

Ne vaudrait-il pas mieux utiliser une variable globale (maxspeed =
EN_VILLE_PAR_DEFAUT) pour exprimer la vitesse maxi d’une rue quand il n’y a
pas de panneau ?

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

Re: [OSM-talk-fr] Voie véhicules lents

[djakk djakk]

Salut ! C’en est fini de la limitation de vitesse à 60 km/h sur les voies
pour véhicules lents, depuis une quinzaine d’années ;)


Julien djakk

Le lun. 25 juin 2018 à 12:21, Philippe Verdy  a écrit :

> Ce n'est pas que franco-français, j'en ai vu en Espagne, au Portugal, en
> Andorre, en Allemagne, en Suisse, en Autriche... C'est assez courant sur
> les autoroutes et les grands ponts.
>
> Le 25 juin 2018 à 08:57, David Marchal  a écrit :
>
>> Chers tous,
>>
>>
>> Ma question est simple : comment on modélise ça ? Je n’ai rien trouvé sur
>> le Wiki, et ça a l’air franco-français.
>>
>>
>> Dans l’attente de vos réponses,
>>
>>
>> Cordialement.
>>
>> ___
>> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Zone 30 km/h

[djakk djakk]

Pardon !

Pour représenter une « zone 30 », faut-il créer un polygone avec maxpeed=30
ou tagger toutes les rues avec maxspeed=30 ?


Djakk

Le lun. 25 juin 2018 à 16:05, marc marc  a
écrit :

> Le 25. 06. 18 à 16:03, djakk djakk a écrit :
> > Salut !
> >
> > Polygone ou trait par trait pour les zones limitées à 30 km/h ? ;)
>
> ta question est difficilement compréhensible
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Voie véhicules lents

[djakk djakk]

Mon moniteur d’auto-école de l’époque :D


Le lun. 25 juin 2018 à 17:23, Axelos  a écrit :

> Le 25/06/2018 à 16:02, djakk djakk a écrit :
> > Salut ! C’en est fini de la limitation de vitesse à 60 km/h sur les voies
> > pour véhicules lents, depuis une quinzaine d’années ;)
>
> Tu as une source pour affirmer;
> Lorsque je regarde les textes sur Legifrance, plus précisément l'article
> ci-dessous encore en vigueur :
>
>
> https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI06842322=LEGITEXT06074228
>
> En soit si la voie est exclusivement réservée aux véhicules lents, alors
> en dépassant les 60km on sort bien de la voie.
>
> ___
> 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] conflit de précision de données a cause d'une clé

[djakk djakk]

Moi je dirai qu’on met cycleway='track' quand on a pas le temps d’être
précis.

djakk

Le mar. 20 févr. 2018 à 20:14, Francescu GAROBY  a
écrit :

> En l'occurrence, je vois qu'il a notamment fusionné la piste cyclable qui
> longe le Cours Montalivet avec ce dernier. C'est une erreur ! Il y a une
> rangée d'arbres, sur un parterre large de 2m, qui sépare ces 2 axes.
> Il faut lui dire d'arrêter ça.
>
> Francescu
>
> Le 20 février 2018 à 20:12, marc marc  a écrit
> :
>
>> Le 20. 02. 18 à 19:58, David Crochet a écrit :
>> > Cette clé "cycleway=track", bien que correct, définit moins que la piste
>> > décrite elle-même puisqu'en étant séparé de la voie routière, on peut
>> > définir sa matière de surface ainsi.
>>
>> non, il n'y a pas de différente entre les 2 pour les tags.
>> on peux tout aussi bien décrire tous les caractéristiques avec 2 chemins
>> qu'avec un seul en utilisant les namespaces comme cycleway:surface=*
>> la différence n'est pas là.
>>
>> > Bref, il est partisan de cette clé associé à la voie routière, je suis
>> > partisan de l'autre façon et de le décrire de façon indépendante.
>>
>> c'est un problème sans fin, on en a parlé longuement il y a moins de 2
>> mois ici même.
>> dans osm, la convention est supposé de ne séparer un way en 2 que
>> lorsqu'il y a un obstacle entre les 2 qui empche de passer de l'un
>> à l'autre.
>> c'est capital pour le routing et c'est la seule façon qui fonctionne
>> correctement pour le routing. (=il n'y a pour le moment aucune
>> proposition qui a aboutie pour dire que 2 way séparé sont "sans obstacle
>> entre eux)
>>
>> maintenant d'autres ont envie de gagner qlq cm dans la localisation de
>> la piste cyclable ou du trottoir et ont font 2 way séparés.
>> cette amélioration du rendu se fait selon moi au détriment du routing.
>> donc on dégrade l'un pour améliorer l'autre.
>>
>> Je pense que la seule solution est qu'un partisan de ce schéma travaille
>> pour faire une proposition qui résolve les problèmes de routing qu'elle
>> provoque. car ces propals sont au points mort.
>>
>> Cordialement,
>> Marc
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> Francescu
> ___
> 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] une ou deux way ? 2 ways s'il y a un obstacle.

[djakk djakk]

Merci d’avoir créé un sujet spécifique.

Voilà un bon exemple, en me formant à osm je faisait comme pour la « Route
de la Reine » mais en fait ça serait mieux d’avoir un seul trait pour la
rue et poser dessus 2 noeud pour symboliser les îlots centraux ; si un
cartographe est chaud pour faire de la précision, il pourrait passer aux
surfaces, la plate-forme = une surface et chaque îlot central = une
surface.

C’est comme les voies bus avec muret séparateur, le fait que ça soit sur la
même plate-forme me fait dire qu’il faudrait un seul trait et pas 2.

Je verrai bien une petite révolution dans la manière de cartographier sur
openstreetmap, une plate-forme = un seul trait, même pour les autoroutes :
et si on veut être plus+ précis, on passe à la description du monde avec
les surfaces.
C’est un peu le cas avec les ponts de Paris :
https://www.openstreetmap.org/#map=18/48.85151/2.35152

PS : https://fr.m.wikipedia.org/wiki/Voirie <- pour voir la différence
entre la plate-forme, et la ou les chaussées


djakk



Le mer. 21 févr. 2018 à 14:45, Thomas Ruchin  a écrit :

> Attention, ce n'est pas si évident que cela. Quand on le pratique de
> manière jusqu'au boutiste, cela donne des résultats bizarres
>
> https://www.openstreetmap.org/?mlat=48.83928=2.24425#map=18/48.83928/2.24425
>
> Pour ceux qui connaissent le secteur, heureusement que le Boulevard de
> Magenta à Paris n'est pas cartographié selon la même manière que la Route
> de la Reine à Boulogne
>
> Comme le rappelle Christian, le principal objectif d'avoir des voies
> séparées dans OSM est l'aide au routage. Si la chaussée est la même, il
> faut se poser la question de la pertinence de scinder la voie.
>
> Thomas Ruchin
>
> Le 21 février 2018 à 12:21, Cyrille37 OSM  a
> écrit :
>
>> Le 21/02/2018 à 10:28, Christian Quest a écrit :
>>
>>> Pour moi tout ce qui oblige à faire un choix de passer "à gauche ou à
>>> droite" (donc routage) est un obstacle.
>>> Une bande réservée au stationnement est aussi pour moi un obstacle vu
>>> qu'on va devoir choisir par où passer.
>>>
>>
>> +1
>>
>>
>> ___
>> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Zones géographiques informelles

[djakk djakk]

Oui c’est fuzzy ! Par contre il faut 2 ou 3 géométries, impossible de
mesurer le flou avec un tag fuzzy en mètres, car ça ne sera quasiment
jamais un disque régulier autour d’un point, ou une enveloppe de largeur
identique partout autour d’un polygone.

djakk


Le sam. 24 févr. 2018 à 15:54, Philippe Verdy  a écrit :

> Noter qu'on peut éventuellement indiquer une distance comme "fuzzy=2000"
> (en mètres par défaut), l'absence de tag "fuzzy=*" sur un noeud signifie
> "fuzzy=yes" sur une frontière floue (marquée avec fuzzy=yes), et
> "fuzzy=no" dans tous les autres cas. "fuzzy=no" est équivalent à "fuzzy=0"
> (précis)...
> Cela pourrait servir aussi sur des noeuds isolés pour marquer notamment
> les noeud "place=*" avec le rayon donné dans "fuzzy=*" (exemple: des noms
> de cols, de sommets, et divers lieux naturels non marqués précisément).
> On pourrait aussi indiquer "fuzzy=*" pour indiquer la précision des
> limites de plages en mer, ou la ligne de côte avec la marge d'incertitude
> (là aussi en mètres par défaut).
> C'est une propriété purement géométrique (au même sens que les coordonnées
> en latitude/longitude, ou l'altitude et l'élévation)
>
>
> Le 24 février 2018 à 15:44, Philippe Verdy  a écrit :
>
>>
>> Le 23 février 2018 à 22:13, marc marc  a
>> écrit :
>> > d’ailleurs est ce que estimated (ou approximatif oui c'est du francais
>> Philippe je sais qu'il faut de l'anglais) c'est le bon mot.
>> Le bon mot en anglais c'est "fuzzy". On ne parle pas réellement
>> d'estimation mais bien d'un fait établi (existence de la zone qu'on veut
>> délimiter de façon floue). Alors que "estimated" implique qu'on appelle à
>> plus de précision (chose impossible ici, on ne peut pas faire mieux).
>>
>> Bref je penche pour un tag "fuzzy=yes" sur les ways et c'est suffisant,
>> pas besoin de nouvelles relations (type=boundary, type=multipolygon) ou de
>> nouveaux types de ways fermés (natural=*, laduse=*, etc.), pas besoin de
>> nouveaux rôles (outer/inner suffisent). Avec un tag "fuzzy=no" pour les
>> seuls noeuds d'interconnexion des ways flous avec des frontières précises
>> (et pas besoin de taguer "fuzzy=yes/no" tous les autres noeuds)
>>
>> Shéma ultra-simple compatible avec l'existant. Reste ensuite aux moteurs
>> de rendus de prendre en compte "fuzzy=*" pour ne pas tracer des frontières
>> de façon trop marquée.
>>
>>
> ___
> 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] Zones géographiques informelles

[djakk djakk]

Par exemple : le Vercors : au nord, la limite floue pourrait être entre la
ligne de crête des montagnes et la rivière de l'Isère.
Je ne vois pas comment appliquer une largeur prédéfinie ...

djakk


Le sam. 24 févr. 2018 à 17:13, Philippe Verdy <verd...@wanadoo.fr> a écrit :

> 2 ou trois géométries c'est souvent excessif.
>
> En pratique il suffira d'une seule limite. En avoir plusieurs complique
> énormément le rendu (et là ça nécessite des rôles spéciaux).
>
> Le tag "fuzzy=yes/no/distance en mètres" suffira la plupart du temps pour
> marquer les chemins (et certains noeuds). Et cela suffit aussi pour taguer
> les noeuds isolés dont la précision est floue. (fuzzy=yes n'indique aucune
> distance maximale pour le noeud, mais cette distance peut être sur le way
> qui contient la distance par défaut applicable tout le long du way, sauf
> aux derniers triangles joints à des noeuds "précis" avec "fuzzy=no" ou
> indiquant une précision avec fuzzy=distance en mètres".
>
> Si on met plusieurs géométries, au lieu de créer de nouvelles relations
> (symptôme de la "relationite aiguë"), là je vois plutôt utiliser les
> relations existantes avec des rôles modifiés ("inner"/"outer" deviennent
> "inner_max"/"outer_max" pour que ces extensions maximales puissent être
> facilement ignorées par les rendus qui ne savent pas ce que c'est et ne
> tiendront compte que de l'extension minimale indiquée par "inner"/outer".
> Mais on sait déjà que faire un rendu correct avec plusieurs géométries sera
> compliqué
>
> (comme je l'expliquais cela demande une triangulation de la zone entre les
> deux géométries, puis une interpolation linéaire dans chaque triangle, et
> demande de gérer les trous de l'extension minimale "inner" couverts
> entièrement sans trou dans l'extension minimale avec
> "inner_max"/"outer_max", et cela demande une règle de validité : la surface
> de l'extension minimale doit être entièrement incluse dans l'extension
> maximale, mais les deux peuvent se toucher dans le cas où les deux
> contiennent certaines frontières précises, et il n'y aura aucune
> triangulation entre les deux puisque là la surface entre les deux est nulle)
>
> Je pense que ma solution ici (avec un seul tag "fuzzy=*") permet de gérer
> tous les cas les plus tordus, sans devoir recourir à la duplication
> systématique des géométries (ce qui reste possible mais sera exceptionnel
> quand on sait que c'est compliqué à rendre graphiquement) et en préservant
> la compatibilité maximale.
>
>
> Le 24 février 2018 à 16:51, djakk djakk <djakk.dj...@gmail.com> a écrit :
>
>> Oui c’est fuzzy ! Par contre il faut 2 ou 3 géométries, impossible de
>> mesurer le flou avec un tag fuzzy en mètres, car ça ne sera quasiment
>> jamais un disque régulier autour d’un point, ou une enveloppe de largeur
>> identique partout autour d’un polygone.
>>
>> djakk
>>
>>
>> Le sam. 24 févr. 2018 à 15:54, Philippe Verdy <verd...@wanadoo.fr> a
>> écrit :
>>
>>> Noter qu'on peut éventuellement indiquer une distance comme "fuzzy=2000"
>>> (en mètres par défaut), l'absence de tag "fuzzy=*" sur un noeud signifie
>>> "fuzzy=yes" sur une frontière floue (marquée avec fuzzy=yes), et
>>> "fuzzy=no" dans tous les autres cas. "fuzzy=no" est équivalent à "fuzzy=0"
>>> (précis)...
>>> Cela pourrait servir aussi sur des noeuds isolés pour marquer notamment
>>> les noeud "place=*" avec le rayon donné dans "fuzzy=*" (exemple: des noms
>>> de cols, de sommets, et divers lieux naturels non marqués précisément).
>>> On pourrait aussi indiquer "fuzzy=*" pour indiquer la précision des
>>> limites de plages en mer, ou la ligne de côte avec la marge d'incertitude
>>> (là aussi en mètres par défaut).
>>> C'est une propriété purement géométrique (au même sens que les
>>> coordonnées en latitude/longitude, ou l'altitude et l'élévation)
>>>
>>>
>>> Le 24 février 2018 à 15:44, Philippe Verdy <verd...@wanadoo.fr> a écrit
>>> :
>>>
>>>>
>>>> Le 23 février 2018 à 22:13, marc marc <marc_marc_...@hotmail.com> a
>>>> écrit :
>>>> > d’ailleurs est ce que estimated (ou approximatif oui c'est du
>>>> francais Philippe je sais qu'il faut de l'anglais) c'est le bon mot.
>>>> Le bon mot en anglais c'est "fuzzy". On ne parle pas réellement
>>>> d'estimation mais bien d'un fait établi (existence de la zone qu'on veut
&

Re: [OSM-talk-fr] Usage d'OSM par les services de secours du pays-bas

[djakk djakk]

En France c’est la bande d’arrêt d’urgence qui sert de voie de circulation
aux véhicules d’urgence ;-)


Le sam. 24 févr. 2018 à 17:01, Philippe Verdy  a écrit :

> Je suis admiratif sur la façon dont les conducteurs aux Pays-Bas font de
> leur mieux pour laisser le passage aux véhicules d'urgence, se parquent sur
> les voies d'arrêt d'urgence (en mettant les warnings), n'entrent pas dans
> un carrefour même si le feu est vert pour eux, et signalent même les
> véhicules devant eux pour leur signaler et faire la même chose. Et tout le
> monde respecte ça, il n'y en a pas qui profitent de ce dégagement de la
> voie pour doubler une file dans un bouchon et passer devant le véhicule
> d'urgence.
>
> Même dans le cas d'une bretelle de sortie où il y a une réduction du
> nombre de voies, ils n'hésitent pas à s'arrêter (et allumer leur warning)
> sur leur voie, pour ne pas fusionner dans la voie unique qu'ils laissent
> libre pour le passage de l'ambulance. La voie d'arrêt d'urgence sur les
> autoroutes et voies express est toujours libre pour pouvoir s'y arrêter et
> laisser le passage en toute sécurité si nécessaire. Les conducteurs
> néerlandais sont prévoyants (hormis le cas d'un seul camion dans la vidéo
> qui est passé et a bloqué le passage du véhicule d'urgence, il devait être
> étourdi mais il était le seul).
>
> Même les camions et certains véhicules respectent ça et sont équipés pour
> certains de feux clignotants spéciaux (à clignotement rapide) pour signaler
> au véhicule d'urgence qu'ils ont laissé un passage libre sur la voie qu'ils
> ont dégagé (les autres véhicules utilisent au minimum leurs feux "warning"
> quand ils manœuvrent pour se ranger).
>
> On n'a pas les même comportements en France, par exemple sur les bandes
> d'arrêt d'urgence sur nos autoroutes ou sur les périphériques parisiens ou
> nantais (sans toutefois atteindre les sommets de l'imprudence et
> l'incivilité qu'on voit en Russie, où nombre de conducteurs plus prudents
> ont installé des caméras embarquées avec enregistrement dans leur véhicule
> pour faire preuve et témoigner des imprudences des autres : les vidéos
> d'accidents en Russie, prises avec ces caméras embarquées, sont terribles
> et ça doit être vraiment dangereux pour les véhicules d'urgence d'oser
> franchir un feu rouge même s'ils sont "prioritaires" selon la loi).
>
> 2018-02-24 10:20 GMT+01:00 David Crochet :
>
>> Bonjour
>>
>> petite vidéo avec OSM et surcouches : https://youtu.be/_jGGZq6_6hw?t=334
>>
>> Cordialement
>>
>> --
>> David Crochet
>>
>>
>> ___
>> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Zones géographiques informelles

[djakk djakk]

Noeud, ligne ou surface selon les cas (quartier de ville - fond de vallée -
massif montagneux).
Quant au polygone, quand la limite est floue, en faire un petit et un grand
(cœur de la region - extension maximum de la région) ?


djakk


Le ven. 23 févr. 2018 à 17:58, Philippe Verdy  a écrit :

> Je ne vois pas mettre ça dans les rôles des membres de relations, mais
> directement comme tags des chemins tracés... Le rôle est strictement le
> même ce n'est que la précision du tracé qui est floue (en fait la précision
> des noeuds utilisés, mais on na va pas taguer nécessairement tous les
> noeuds d'un chemin, d'autant plus que ce tracé peut passer ou coïncider
> localement à des points précis (ils le seront s'ils ont des tags utiles,
> non ignorés, c'est à dire non suppressibles automatiquement comme les tags
> d'import automatique, ainsi que certains tags purement informatifs comme
> "note=*" ou "source=*").
>
> Ajouter des rôles (en plus avec un nom anglo-français horrible ) ne va
> pas aider du tout. C'est la géométrie qui est concernée (donc au plus près
> du tracé de bas niveau, donc sur les noeuds, voire les chemins si ce sont
> de noeuds "anonymes").
>
> Le 23 février 2018 à 14:53, Jérôme Amagat  a
> écrit :
>
>> Un node c'est déjà pas mal mais on perd pas mal par rapport a un polygone
>> au niveau de la taille, de l’étendu.
>> Pour les lieux habités place=city town village hamlet ... on a une idée
>> de la taille dans le tag mais comment ont fait pour différencier par
>> exemple les Alpes et un de ses massifs?
>>
>> Un truc que je trouverais pas mal c'est créer une relation multipolygon
>> avec des membres qui ont des rôles du type "outer_approximatif" voir
>> "outer_approximatif:1000m" par exemple, tous les "cotés" de la zone n'ayant
>> pas le même problème pour être fixés, parfois ça s’arrête sur une rivière,
>> une cote, une crête de montagne ou au milieu de nul part.
>>
>> Les limites de la zone ne sont pas le seul problème, quel tag doit on
>> utiliser?
>> Il n'y a rien (ou presque) sur le wiki.
>> Est ce que c'est juste pour placer un nom ou bien faut t il un tag qui
>> donne la raison d’être de ce nom comme une zone liée à son relief (une
>> vallée, une plaine, un massif montagneux), à son histoire ou à autre chose.
>>
>> Deja present dans osm ont peut trouver avec taginfo :
>> des chose en *=mountain_range
>> des natural=plain, natural=plateau
>> ...
>> Pour les vallée il y a
>>
>> J'ai créé quelque "truc" il y a quelques temps :
>> La Bresse : https://www.openstreetmap.org/relation/3078437
>> La Dombes : https://www.openstreetmap.org/relation/3078442
>> Le Jura Français (les communes en zone de montagne donc c'est du naturel
>> lié a de l'administratif)
>>
>>
>> ___
>> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] cycleway=track et bifurcations

[djakk djakk]

Pour moi, on fusionne piste cyclable et route pour voitures avec
cycleway=track quand on a pas le temps de cartographier plus précisément.

Pour ce cas dont tu parles, on pourrait s’en sortir en codant une
séparation route - piste cyclable sur une petite portion de rue autour du
carrefour.

djakk


Le jeu. 22 févr. 2018 à 22:07,  a écrit :

> Si on a une route principale avec une piste à côté taguée cycleway=track,
> peut-on indiquer que lors d'un carrefour que la voie n'est pas empruntable
> depuis la piste cyclable ?
>
> Si la route débouchant sur la route principale est du côté opposé, comme
> c'est une piste et non une bande cyclable, est-ce que ça ne va pas de soi ?
>
> Sauf qu'au niveau du rendu sur la carte, comme au niveau des moteurs de
> navigation certaines subtilités échappent.
>
> Jean-Yvon
>
> N.B. : je ne suis pas spécialement partisan de cycleway=track, je cherche
> juste des cas incompatibles avec une telle description, au moins des cas où
> la représentation est plus difficile qu'avec une voirie tracée en propre
> (par exemple on pourrait mettre des restrictions pour dire explicitement
> que c'est impossible.
> ___
> 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] conflit de précision de données a cause d'une clé

[djakk djakk]

Au fait, je remarque qu’on ne taggue pas pour le rendu, par contre on
taggue pour le calcul d’itineraire  :)

Le mer. 21 févr. 2018 à 12:49, Axelos  a écrit :

> Le 21/02/2018 à 12:14, Francescu GAROBY a écrit :
> > Bonjour Axel (et les autres),
> > Ça tombe bien que tu demandes des photos, car je comptais dès hier soir
> > vous en faire ce matin, vu que le Cours Montalivet est justement mon
> > itinéraire quotidien à vélo. Les voici donc, hébergées sur framapic.
> > Pour commencer, il faut savoir qu'il n'existe aucun aménagement cyclable
> > coté sud du Cours Montalivet : uniquement des contre-allées, ouvertes à
> > tous, permettant de desservir les magasins qui s'y trouvent. Mon trajet
> se
> > fait donc dans le sens ouest -> est, au nord du Cours (entre ce dernier
> et
> > l'Orne).
> >
> > * 1ère photo 
> (prise ici
> > <
> https://www.openstreetmap.org/?mlat=49.17931=-0.34844#map=19/49.17931/-0.34844
> >
> > dans le sens sud -> nord), la jonction entre le Cours et la piste
> cyclable
> > se fait par un feu tricolore commun avec les piétons et, du fait des
> > travaux actuels, il est même demandé aux cyclistes de traverser pied à
> > terre.
>
>
> Dû à la présence de travaux, il est peut-être préférable de laisser tel
> quel pour le moment (highway=footway + bicycle=yes).
>
>
> > * 2ème photo 
> (prise ici
> > <
> https://www.openstreetmap.org/?mlat=49.17953=-0.34857#map=19/49.17953/-0.34857
> >),
> > la piste est bidirectionnelle, et large (1m80, avec tout de même quelques
> > rétrécissements, parfois dangereux, à certains endroits. Mais jamais
> moins
> > de 1m de large). À noter aussi la bande de terre herbeuse et arborée, qui
> > sépare la piste de la chaussée. Par endroit, le trottoir dépasse les 20cm
> > de hauteur !
> > * 3ème  et 4ème
> >  photos (prises ici
> > <
> https://www.openstreetmap.org/?mlat=49.17962=-0.34817#map=19/49.17962/-0.34817
> >
> > et là
> > <
> https://www.openstreetmap.org/?mlat=49.17951=-0.33435#map=17/49.17951/-0.33435
> >)
> > : pour comparaison, le Cours a lui aussi un terre-plein central herbeux
> et
> > arboré. Puis uniquement herbeux et de la hauteur d'une petite motte de
> > terre. Facilement franchissable par n'importe qui ! Même type de
> > séparation, mais personne ne conteste la séparation physique des 2 axes
> de
> > circulation.
> > * 5ème photo  : la
> > piste a son propre revêtement. Il est séparé de la chaussée, pas refait
> au
> > même moment, et même, par endroits, composé uniquement de plaques de
> béton,
> > et non de bitume ! On voit d'ailleurs sur la photo qu'il a aussi son
> propre
> > état : les racines des arbres soulèvent le bitume. Comme le Cours est
> plus
> > souvent refait que la piste, ça ne se remarque que sur cette dernière...
> > * 6ème photo 
> (prise ici
> > <
> https://www.openstreetmap.org/?mlat=49.18284=-0.31795#map=18/49.18284/-0.31795
> >)
> > : cependant, les 20-30 derniers mètres de la piste, à l'approche de sa
> > jonction avec le carrefour Cours Montalivet/Route de Cabourg, sont
> > différents, en effet. Plus de séparation physique par un terre-plein. Là,
> > qu'on dise que c'est du "track", pourquoi pas.
>
>
> Les photos correspondent au cas T2 de la page bicycle
> http://wiki.osm.org/wiki/FR:Bicycle , qui recommande deux chemins
> séparées.
>
> Donc la modification est bien une régression.
>
> > Bref, pour moi, il est clair qu'il s'agit d'une piste cyclable
> > ("highway=cycleway"), et non d'autre chose (mis à part les 20-30 derniers
> > mètres, à l'extrémité est). D'ailleurs (j'ai oublié de prendre une photo
> > spécifique, pour ça), les jonctions entre le Cours et la piste sont
> > inexistantes (mis à part aux extrémités et aux rares passages-piétons) !
> > Par exemple, il n'est pas possible d'aller des contre-allées coté sud du
> > Cours, telle que l'allée du Bac, jusqu'à la piste cyclable
> > <
> https://www.openstreetmap.org/?mlat=49.17923=-0.33429#map=18/49.17923/-0.33429
> >
> > : aucun aménagement (trottoir rabaissé/bateau, passage-piétons, ...)
> > n'existe ! Inclure la piste au way du Cours Montalivet trompera les
> > calculateurs d'itinéraires, et mettra en danger les cyclistes qui s'y
> > fieraient.
>
>
> Concernant le routage, un point qui peut aussi déterminer la situation,
> c'est la signalisation. On voit sur la dernière photo un panneau B40
> (Fin de piste ou bande cyclable obligatoire pour cyclistes et
> éventuellement cyclomoteurs, sans side-car ou remorque), y a-t-il en
> amont un panneau B22a qui débute cette obligation ?
> http://wiki.osm.org/w/images/8/82/France_road_sign_B22a.svg
>
> Ce type de signalisation interdit donc d'emprunter les voies de
> circulations parallèles de la 

[OSM-talk-fr] Voies

[djakk djakk]

Salut,

une question sur les voies non séparées par une barrière, comme les voies
d’acceleration, les tourne-à-gauche et les multiples voies d’un péage : une
« way » spécifique ou pas ?
Je croyais que non, mais en voyant que certains font l’inverse, je
m’interroge.
Tourne-à-gauche en Californie :
https://www.openstreetmap.org/#map=19/37.29258/-121.99091
Péage de l’A1 en France métropolitaine :
https://www.openstreetmap.org/#map=16/49.2152/2.628


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