Re: [talk-ph] Philippine multilingual place names (English/native language)

[Eugene Alvin Villar]

On Wed, Aug 23, 2017 at 9:23 AM, Jherome Miguel 
wrote:

>
> It already looks important to have place names under the name= tag be
> bilingual or multilingual, not just in English, especially when taking
> regard speakers of native languages (Tagalog, Cebuano, Hiligaynon,
> Kapampangan, Ilocano, etc.), and use of native. I am proposing a scheme
> where the name under the place tag would have English as first name, and
> second name in the Tagalog (usually formal), and the third name in the
> native language (on places other than those in Tagalog speaking areas)
>

[Oops. Sent too early.]

So in essence, you want to propose something like what is done in Belgium?

I don't agree. I want the name=* to use just a single name, defaulting to
English as much as possible (since English is an official language of the
Philippines) and avoiding Tagalog/Filipino because that is a sensitive
issue outside of native Tagalog-speaking areas.

The only time we will use non-native English names is when the native form
is overwhelmingly used even in English texts such as in English news
articles, English books, and English academic papers. For example, in
practically every English news article about the Marcos burial issue, every
news outlet used the name "Libingan ng mga Bayani" instead of "Cemetery of
Heroes" or "Heroes' Cemetery". So name=Libingan ng mga Bayani is used. This
goes for other places such as "Liwasang Bonifacio" (not "Bonifacio Park" or
"Bonifacio Square" or "Bonifacio Plaza"), "Malacañang sa Sugbo" (not
"Malacañang in Cebu"), "Paseo de Roxas" (not "Roxas Path"), "Zamboanga del
Norte" (not "Northern Zamboanga"), etc.

~Eugene
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [talk-ph] Philippine multilingual place names (English/native language)

[Eugene Alvin Villar]

On Wed, Aug 23, 2017 at 9:23 AM, Jherome Miguel 
wrote:

>
> It already looks important to have place names under the name= tag be
> bilingual or multilingual, not just in English, especially when taking
> regard speakers of native languages (Tagalog, Cebuano, Hiligaynon,
> Kapampangan, Ilocano, etc.), and use of native. I am proposing a scheme
> where the name under the place tag would have English as first name, and
> second name in the Tagalog (usually formal), and the third name in the
> native language (on places other than those in Tagalog speaking areas)
>

So in essence, you want to propose something like what is done in Belgium
or Switzerland?
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

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

[Martin Koppenhoefer]

sent from a phone

> On 23. Aug 2017, at 01:20, Greg Troxel  wrote:
> 
> maxspeed:practical should be a representative speed that's valid most of
> the time.
> 
>> maxspeed:practical should not have any values above the legal speed
>> limit.. and if it had routers should ignore such values anyway, at 
>> least thats what I would expect from navigation software.
>> Many years ago something like this was encouraged in the ancient 
>> proposal but it is no longer in the description.. if there is any 
>> remaining doubt I would explicitly state it in the wiki.
> 
> Show Quoted Content
>> maxspeed:practical should not have any values above the legal speed
>> limit.. and if it had routers should ignore such values anyway, at 
>> least thats what I would expect from navigation software.
>> Many years ago something like this was encouraged in the ancient 
>> proposal but it is no longer in the description.. if there is any 
>> remaining doubt I would explicitly state it in the wiki.
> 
> 
> This seems unreasonable.  Maybe where you are people follow speed limits
> (because they are enforced, or because speed limits are set by good
> engineering practice instead of arbitrarily)


yes, I see several situations where tagging additionally maxspeed:practical or 
typical would be interesting:

a) small/windy/unpaved roads without posted speed limits 
where the default speed limit is far from what you can reasonably and safely 
drive

b) situations where the posted speed limit is off the actual context, so that 
nobody respects it and the police doesn't enforce it

c) situations where there's a reason for a specific speed limit but still 
nobody respects it and the police doesn't enforce it.
Around here, on a big arterial road with 2+3+3+2 lanes (10), some months ago 
the city posted 30kph signs on all lanes and directions (before 50 but people 
went and still go 70-100 on the central lanes), presumably to postpone 
maintenance work without risking to being held responsible in case of an 
accident.


cheers,
Martin ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[talk-ph] Philippine multilingual place names (English/native language)

[Jherome Miguel]

It already looks important to have place names under the name= tag be
bilingual or multilingual, not just in English, especially when taking
regard speakers of native languages (Tagalog, Cebuano, Hiligaynon,
Kapampangan, Ilocano, etc.), and use of native. I am proposing a scheme
where the name under the place tag would have English as first name, and
second name in the Tagalog (usually formal), and the third name in the
native language (on places other than those in Tagalog speaking areas)

This may look like this, on populated places,

Manila - Manila/Maynila (English/Tagalog)
Caloocan - Caloocan/Kalookan (English/Tagalog)
Quezon City - Quezon City/Lungsod Quezon (English/Tagalog)
Batangas City - Batangas City/Lungsod ng Batangas (English/Tagalog)
Cavite City - Cavite City/Lungsod ng Kabite/Ciudad de Cavite
 (English/Tagalog/Chavacano)
Cebu City - Cebu City/Lungsod ng Cebu/Dakbanwa sa Sugbu (English/Tagalog or
Filipino/Cebuano)
Zamboanga - Zamboanga City/Lungsod ng Zamboanga/Ciudad de Zamboanga
(English/Tagalog or Filipino/Cebuano)

on select places where a native name is used along with an English and/or
Filipino name

Bonifacio Shrine - Bonifacio Shrine/Liwasang Bonifacio

and on other geographical features

Pasig River - Pasig River/Ilog Pasig
Mount Makiling - Mount Makiling/Bundok Makiling
Verde Island - Verde Island/Isla Verde
Mount Mayon - Mount Mayon/Bulkang Mayon/Bulkang Magayon

But where the native name is primarily used, the English name (translation,
may or may not be signed) comes second.

Though use of bilingual or multilingual names may only apply where a known
native name is used, this may help to those who are not accustomed to
English when browsing. But not all names are to use the
bilingual/multilingual ones. Only where a known native name is used
(whether spoken or signed) where a bilingual or multilingual name is to be
used.

Any comments with the proposal welcome.
--TagaSanPedroAko
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[OSM-ja] JOSMの妥当性検査のルールはどこ?(bridge:name,tunnel:nameタグの警告を消したい)

[Jun NOGATA]

こんにちは。野方です。

変更セットのコメントで「橋の名前とトンネルの名前タグにbridge_name,
tunnel_nameタグを使ってましたが、bridge:name, tunnel:nameに修正しました」
とコメントをいただきました。
http://www.openstreetmap.org/changeset/50036674

確かJOSMの妥当性検査で警告が出て直した記憶があったので確認すると、
tunnel:nameタグの部分で
「プロパティキーの綴り間違い-'tunnel:name'キーは'tunnel_name'ではないでしょうか」
と警告が出ます

bridge:name, tunnel:nameの警告を無効にしたいと思うのですが、
ルールはJOSMのどこで定義されているのでしょうか。

--
野方 純 (NOGATA,Jun) - mail: noga...@gmail.com
 - web: http://www.nofuture.tv/diary/
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

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

[Greg Troxel]

john whelan  writes:

>>A typical city road posted 30 mph might move at 35 mph,

I probably should not have said city, but maybe town.  Around me, things
are less crowded and the speeds I referenced are not irresponsible.

> As someone who lives in a city street with one school in the middle and one
> at either end posted at 40 km/h with an average traffic speed of 60 km/h
> and over 100 km/h from some high school kids driving to and from school I
> would prefer it if traffic stuck to the posted speed limits.  Cars running
> across front lawns to avoid collisions are not unknown.

That sounds crazy, but I would guess that it isn't the people actually
paying attention going 48 that are the real issue!  But in all
seriousness, that sounds like an actual problem, not an OSM
representation problem.



signature.asc
Description: PGP signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[john whelan]

>A typical city road posted 30 mph might move at 35 mph,

As someone who lives in a city street with one school in the middle and one
at either end posted at 40 km/h with an average traffic speed of 60 km/h
and over 100 km/h from some high school kids driving to and from school I
would prefer it if traffic stuck to the posted speed limits.  Cars running
across front lawns to avoid collisions are not unknown.

Cheerio John

On 22 Aug 2017 7:23 pm, "Greg Troxel"  wrote:

>
> Richard  writes:
>
> > On Tue, Aug 22, 2017 at 10:00:07PM +0200, Martin Koppenhoefer wrote:
> >>
> >>
> >> sent from a phone
> >>
> >> > On 22. Aug 2017, at 15:46, Richard  wrote:
> >> >
> >> > called differently, but this is it:
> >> > https://wiki.openstreetmap.org/wiki/Key:maxspeed:practical
> >>
> >>
> >> yes, but practical maxspeed depends a lot on your equipment and
> >> capabilities, and on other people driving in front of you, so this
> >> tag will probably not be very uniform around the globe. Also, some
> >> people are willing to risk a speeding ticket, others don't. With
> >> regard to the latter, the situation in Italy is particularly
> >> ridiculous: the authorities have to sign post speed controls ;-)
> >> i.e. speeding tickets are kind of rare.
>
> In most US states, there's a de facto limit higher than the signed limit
> where there is very little risk of a ticket.  I'm thinking that
> maxspeed:practical should be the 50th percentile of typical time actual
> speeds.
>
> > maxspeed:practical should take dense account or traffic jams into
> > account as good as possible. So far I am not aware of any router
> > evaluating time based conditional restrictions but those could be
> > used to take rush hours somewhat into account.
>
> Agreed.  Or even live traffic.  But I agree with the notion that
> maxspeed:practical should be a representative speed that's valid most of
> the time.
>
> > maxspeed:practical should not have any values above the legal speed
> > limit.. and if it had routers should ignore such values anyway, at
> > least thats what I would expect from navigation software.
> > Many years ago something like this was encouraged in the ancient
> > proposal but it is no longer in the description.. if there is any
> > remaining doubt I would explicitly state it in the wiki.
>
> This seems unreasonable.  Maybe where you are people follow speed limits
> (because they are enforced, or because speed limits are set by good
> engineering practice instead of arbitrarily).  In that case, though,
> maxspeed:practical will be essentially maxspeed anyway, and that's fine.
> But in Massachusetts, uncongested traffic in clear weather essentially
> always travels above the speed limit, and the delta varies by road type.
> A typical city road posted 30 mph might move at 35 mph, and an
> Interstate posted 65 mph might move at 80 mph.  But a particular road
> that's almost Interstate (and correctly tagged trunk!) that is
> inexplicably posted at 45 mph moves at 75 mph, because that's what all
> the drivers think is the safe speed.
>
> A router should be answering the question "If I take this route, what
> will happen" as accurately as possible, as a first step in choosing a
> route with a pleasing outcome.  Refusing to use a reasonable estimate of
> traffic flow because it's below an arbitrary, known not to be enforced
> limit, does users of the routing service a disservice.
>
> (I don't know what Apple maps does, but I think they use speed estimates
> from other apple users and do not clamp them to speed limits.  At least
> it seems that way in that Apple computes routes that are in fact fast
> but would be slower if speed limits were observed.)
>
> Computing a route based on what's known to happen is not the same thing
> as encouraging speeding -- it's more like admitting that it usually
> happens.  And in all cases the driver is deciding how to drive.
>
> So:
>
>   maxspeed:practical should be able to have higher values than maxspeed
>
>   routers should use those values, higher or not
>
> and if that's not ok, then we need
>
>   maxspeed:typical
>
> which is defined to be what usually happens, regardless of what anybody
> thinks about it.
>
> Greg
>
>
> ___
> 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 ?

[Greg Troxel]

Lester Caine  writes:

> http://map.project-osrm.org/?z=11=52.149501%2C-1.577225=52.048797%2C-1.856918=52.258912%2C-1.619625=en=0
>
> 43.4km 33min
>
> Dragged to normal route via Mickleton it becomes 32.3km 34min, but
> anybody who uses this section of the A46 will tell you that it's often
> stationary traffic even on the dual bits ... so the quoted times are
> simply wrong a lot of the time.
>
> To add to the fun Warwickshire has decided they will enforce a county
> wide 50MPH maximum overriding the national limit so some of the long
> straight sections we 'should' be slowing down while some sections of the
> A46 are 70, but the same 50 limit applies to other long stretches on the
> A46 as well ;)
>
> I have a smaller problem heading south to the M5 and again 'shortest'
> picks the quick route but then avoids the M5 as well :) Interesting ...
> checking OSRM is getting it right so I need to check OSMAND again on that.

If I drag the start point NE just a bit it flips to the route you like.

I don't have enough Copious Spare Time, but I'd like to see a way for
routers to export their estimates of time/distance per leg, and to match
that up with GPX, and essentially find legs with bad estimates, so they
can be looked at indvidually.  This is more complicated because there is
intersection behavior, so I think it needs to have time for the middle
leg out of 3, or something that I haven't figured out, but still, one
should be able to ask "Did what the router said would happen happen".

Dealing with traffic is much harder.  For that I lean to a separate
database pouplated with reports by time/date and some inference, but
that's hard.


signature.asc
Description: PGP signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Greg Troxel]

Philip Barnes  writes:

> On 22 August 2017 14:46:33 BST, Richard  wrote:
>>On Tue, Aug 22, 2017 at 08:40:13AM -0400, Greg Troxel wrote:
>>> 
>>> Two points:
>>> 
>>>   Speed limit does not describe the speeds that reasonably
>>responsible
>>>   real people actually drive on roads.  The UK/IE notion of 60 mph on
>>>   all roads out of village centers is one example.  Another is in the
>>US
>>>   where there are many roads signed 65 mph where traffic normally
>>moves
>>>   at 80 mph.  So, what I think OSM needs a few things:
>>> 
>>> - A) a "typical_speed" tag, to be used by routers instead of
>>>   speed_limit
>>
>>called differently, but this is it:
>>https://wiki.openstreetmap.org/wiki/Key:maxspeed:practical
>>
> Isn"t that going to be rather subjective?

That's why I picked "typical" rather than "pracical" (not knowing about
:practical, until Richard pointed it out).

I don't see it as subjective.  You just measure the median speed of cars
that go by every our, and take the median of that, or something similar.
It's meant to represent what typically happens, absent terrible traffic
jams (which affect all the other roads).  And, if there's a value that's
meant to approximate the true, too hard-to-measure definition, and it's
close to correct, that's in many cases better than using maxspeed
(around me, anyway).  I don't really anticipate edit wars over this.



signature.asc
Description: PGP signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Greg Troxel]

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


signature.asc
Description: PGP signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Greg Troxel]

Richard  writes:

> On Tue, Aug 22, 2017 at 10:00:07PM +0200, Martin Koppenhoefer wrote:
>> 
>> 
>> sent from a phone
>> 
>> > On 22. Aug 2017, at 15:46, Richard  wrote:
>> > 
>> > called differently, but this is it:
>> > https://wiki.openstreetmap.org/wiki/Key:maxspeed:practical
>> 
>> 
>> yes, but practical maxspeed depends a lot on your equipment and
>> capabilities, and on other people driving in front of you, so this
>> tag will probably not be very uniform around the globe. Also, some
>> people are willing to risk a speeding ticket, others don't. With
>> regard to the latter, the situation in Italy is particularly
>> ridiculous: the authorities have to sign post speed controls ;-)
>> i.e. speeding tickets are kind of rare.

In most US states, there's a de facto limit higher than the signed limit
where there is very little risk of a ticket.  I'm thinking that
maxspeed:practical should be the 50th percentile of typical time actual
speeds.

> maxspeed:practical should take dense account or traffic jams into 
> account as good as possible. So far I am not aware of any router
> evaluating time based conditional restrictions but those could be
> used to take rush hours somewhat into account.

Agreed.  Or even live traffic.  But I agree with the notion that
maxspeed:practical should be a representative speed that's valid most of
the time.

> maxspeed:practical should not have any values above the legal speed
> limit.. and if it had routers should ignore such values anyway, at 
> least thats what I would expect from navigation software.
> Many years ago something like this was encouraged in the ancient 
> proposal but it is no longer in the description.. if there is any 
> remaining doubt I would explicitly state it in the wiki.

This seems unreasonable.  Maybe where you are people follow speed limits
(because they are enforced, or because speed limits are set by good
engineering practice instead of arbitrarily).  In that case, though,
maxspeed:practical will be essentially maxspeed anyway, and that's fine.
But in Massachusetts, uncongested traffic in clear weather essentially
always travels above the speed limit, and the delta varies by road type.
A typical city road posted 30 mph might move at 35 mph, and an
Interstate posted 65 mph might move at 80 mph.  But a particular road
that's almost Interstate (and correctly tagged trunk!) that is
inexplicably posted at 45 mph moves at 75 mph, because that's what all
the drivers think is the safe speed.

A router should be answering the question "If I take this route, what
will happen" as accurately as possible, as a first step in choosing a
route with a pleasing outcome.  Refusing to use a reasonable estimate of
traffic flow because it's below an arbitrary, known not to be enforced
limit, does users of the routing service a disservice.

(I don't know what Apple maps does, but I think they use speed estimates
from other apple users and do not clamp them to speed limits.  At least
it seems that way in that Apple computes routes that are in fact fast
but would be slower if speed limits were observed.)

Computing a route based on what's known to happen is not the same thing
as encouraging speeding -- it's more like admitting that it usually
happens.  And in all cases the driver is deciding how to drive.

So:

  maxspeed:practical should be able to have higher values than maxspeed

  routers should use those values, higher or not

and if that's not ok, then we need

  maxspeed:typical

which is defined to be what usually happens, regardless of what anybody
thinks about it.

Greg



signature.asc
Description: PGP signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

[François Lacombe]

Le 23 août 2017 à 00:12, marc marc  a écrit :

> Le 22. 08. 17 à 22:58, François Lacombe a écrit :
> > il est vrai que la proposition concerne aussi le tag flow_capacity
> > capacity:flow je trouve flow assez générique. vois-tu un autre tag
> avec
> > flow possible ? parce que sinon c'est un peu l'inverse de type, ce
> serra
> > un tag tellement précis qu'il n'existe qu'avec capacity et dans ce
> cas
> > flow_capacity serrait tout aussi bien.
> > Si t'as un exemple d'autre "flow", je me rangerai à ton avis.
> > Je suis ok pour dire que ce n'est que de la forme et je n'ai pas trouvé
> > d'autre clé qui puisse aller avec flow.
> j'ai trouvé ton sauveur :) il y a bien capacity:disabled alors qu'il n'y
> pas d'autre clef :disabled
>

Il y a aussi sur la page du wiki :parent qui selon taginfo est seul (il y a
des :parent mais dans le sens de l'ascendance et pas du rôle de
parent/enfants)

capacity:flow va aussi servir pour les pipelines (en remplacement du
"free-text" capacity pour l'instant) et des choses comme waterway=drain et
tunnel=culvert
Il y a les prises d'eau en rivière aussi, il y a vraiment plein de cas
d'utilisation.


> alors pourquoi pas capacity:flow si tu penses que c'est utile.
> cela m’embête un peu parce que je trouve ennuyeux qu'on casse l'unicité
> de l'unité par défaut de capacity (nombre sans unité).
> mais vas-y si tu penses que capacity:flow est bien mieux que flow_capacity
>

Je pense aussi que si la situation est celle-ci aujourd'hui, c'est que le
cas ne s'est pas présenté.
Connaitre le dimensionnement d'une infrastructure est pas si facile que ca
et en dehors des places de parking ou de lit d'hotel, ce n'est pas ce qui
intéresse en premier.
Et il y a bien une unité à toutes ces grandeurs. Elles n'ont par contre pas
de dimension (un detail ce dernier point, j'ai compris ce que tu voulais
dire).
Au niveau industriel, c'est hyper intéressant pourtant et ca place OSM loin
loin devant toute l'opendata que les acteurs intéressés peuvent aujourd'hui
produire.


> > pourquoi rajouter un nouveau tag à discuter ?
> > la proposition ne touche pas à ce tag
> > Parce que c'est dans le sujet traité et que le temps manque aussi.
> Je n'ai pas compris. niveau temps, il vaut mieux circonscrire la
> proposition au lieu de l'étendre chaque semaine, non ?
>

Non, c'est qu'en ce moment nous y consacrons tous du temps, autant en tirer
un maximum de profit (de tag, de cas décris et connus,...)
Plus tard, nous aurons peut-etre tous autre chose à faire, c'est dans ce
sens là que je l'entendais

J'ai ça à faire voter également bientôt quand j'aurais fini les dernier
réglages
https://wiki.openstreetmap.org/wiki/Proposed_features/Transformer_extension_proposal

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

Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

[marc marc]

Le 22. 08. 17 à 22:58, François Lacombe a écrit :
> il est vrai que la proposition concerne aussi le tag flow_capacity
> capacity:flow je trouve flow assez générique. vois-tu un autre tag avec
> flow possible ? parce que sinon c'est un peu l'inverse de type, ce serra
> un tag tellement précis qu'il n'existe qu'avec capacity et dans ce cas
> flow_capacity serrait tout aussi bien.
> Si t'as un exemple d'autre "flow", je me rangerai à ton avis.
> Je suis ok pour dire que ce n'est que de la forme et je n'ai pas trouvé 
> d'autre clé qui puisse aller avec flow.
j'ai trouvé ton sauveur :) il y a bien capacity:disabled alors qu'il n'y 
pas d'autre clef :disabled
alors pourquoi pas capacity:flow si tu penses que c'est utile.
cela m’embête un peu parce que je trouve ennuyeux qu'on casse l'unicité 
de l'unité par défaut de capacity (nombre sans unité).
mais vas-y si tu penses que capacity:flow est bien mieux que flow_capacity

> pourquoi rajouter un nouveau tag à discuter ? 
> la proposition ne touche pas à ce tag
> Parce que c'est dans le sujet traité et que le temps manque aussi.
Je n'ai pas compris. niveau temps, il vaut mieux circonscrire la 
proposition au lieu de l'étendre chaque semaine, non ?
mais si tu penses qu'il faut rajouter les capacités de connexion pour 
faire passer par cohérence les capacités de débit, vas-y
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr - communication - fragmentation

[Christian Rogel]

> Le 2017 Eost 22 à 17:44, Jean-Marc Liotier  a écrit :
> 
> On Tue, 22 Aug 2017 14:21:00 +
> marc marc  wrote:
>> 
>> pour rebondir sur ton exemple, 16 ml locales, quasi + que d'actif.
>> un paquet n'a pas eu de message cette année, une partie est à 1/mois
>> n'est-on pas allez trop loin ? 5 ne serraient-ils pas suffisant ?
> 
> Une partie de ces listes sont en pratique plutôt des canaux de diffusion
> d'annonces et non des lieux de discussion - la spécificité nationale
> est donc peut-être importante, malgré l'apparence d'insignifiance.
> J'ignore si les abonnés en sont satisfaits.


Personnellement, je n’ai jamais compris pourquoi les mappeurs geeks français 
(ils se reconnaîtront) ont mis un point d’honneur à créer leurs micro-ML 
ultra-locales sur des protocoles improbables au lieu de les faire héberger par 
la Fondation et bénéficier de plus de visibilité.
En Bretagne, nous avons pensé que le plus simple et le plus évident était de ne 
pas se montrer séparatiste (;-) ) et, grâce à Émilie, Steven LR a créé, en 
2009, la ML OSM en Bretagne qui figure dans les tablettes de notre organisme de 
référence.
Son trafic est, en moyenne, autour du message/jour et c’est très bien ainsi.
Cela peut tenir à une bonne dimension géographique. Pourquoi une ML à Grenoble 
et une autre à Lyon ? N’a-t’on pas ,mis sur la touche Privas, Thonon et Nyons ? 
ou même, soyons hardis, Saint-Étienne ?  ;-)


Christian R.


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

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

[Richard]

On Tue, Aug 22, 2017 at 05:19:13PM +0100, Philip Barnes wrote:

> >called differently, but this is it:
> >https://wiki.openstreetmap.org/wiki/Key:maxspeed:practical
> >
> Isn"t that going to be rather subjective?

the number will be subjective. It is for the situations that
can't be adequately mapped othwerwise.

Richard

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

Re: [OSM-talk-fr] OSM à la plage;-) - rendu des côtes osm et osm-fr

[Philippe Verdy]

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

> *Philippe, je parlait de la couleur de la Vilaine, au niveau du tuyau
> surmonté d'une surface gravillonnée, j'ai du mal à penser à de belles
> vallées à côté*.
>
Pas besoin de sortir de Rennes pour retrouver une couleur d'eau correcte.
L'Ille apporte une assez belle eau juste au confluent de la Place de
Bretagne et l'Ille (canalisée sur sa plus grande partie avale) est très
prisée par les balades. L'Ille et le canal sont l'objet d'une protection
reconnue depuis longtemps, et on y pratique les sports nautiques toute
l'année (avec un club connu avec pleins de champions à Saint-Grégoire : on
peut y aller aussi à pied depuis Rennes, j'y ai fait du kayak pendant deux
décennies, et c'était pourtant bien avant qu'on commence à mieux traiter
les eaux de la Vilaine à Rennes et éviter les rejets d'égouts directs dans
la Vilaine en notamment centre-ville et la ZI de Chantepie, à
Cesson-Sévigné et à Noyal-sur-Vilaine).

Et toujours dans Rennes les étangs d'Apigné en aval du confluent sont aussi
un lieu de balade qui renaissent (ces étangs, d'anciennes carrières, sont
un espace de décantation et filtrage rendant au cours un peu plus de
clarté). Des efforts sont faits aussi pour améliorer l'eau de la Vilaine en
amont, notamment par le traitement des eaux usées Il y a eu de gros travaux
vers Cesson-Sévigné et Noyal-sur-Vilaine, et d'autres bassins et étangs de
retenue et de décantation sont là (ils ne servent pas qu'à dépolluer mais
aussi à prévenir les inondations à Rennes.

L'eau de la Vilaine est claire dans la zone du Boël à Bruz (célèbre balade
dans la métropole rennaise). Lieu reconquis pour les pêcheurs à la ligne
qui avant devaient se contenter de l'Ille en amont de Rennes à
Saint-Grégoire et pas beaucoup plus bas.

D'autres travaux sont encore nécessaires pour prévenir plus au sud les
inondations dans le goulet de Redon, par la création d'autres bassins de
retenue en amont de Redon (et notamment sur l'Oust et dans la gestion des
eaux du canal de Nantes à Brest du côté de Glénac).

Ensuite sur la frontière entre Loire-Atlantique et Morbihan, pas grand
chose a été fait, le cours est assez large pour absorber la plupart des
crues, et il n'y a pas beaucoup d'activité humaine hormis près de
l'estuaire (mais c'est un fait que la vilaine a causé des problèmes à la
qualité de l'eau sur la grande plage de La Baule, mais la Vilaine n'était
pas seule en cause, la Loire aussi pouvant selon les marées apporter ses
propres pollutions). En entrant complètement dans le Morbihan la Vilaine
passe par une zone de marais très plane, avec un écoulement très lent
(c'est le problème justement qui provoque les inondations à Redon) ; quand
le cours atteint La Roche-Bernard, il est assagi avec peu de crues, et
beaucoup plus propre qu'il ne l'était (là la vilaine était sensible aux
marées et la salinification des marais avant le construction du barrage
d'Arzal qui protège et maintient en eau les ports d'Arzal, Camoël et la
Roche-Bernard, mais surtout évite l'amplification des crues en amont).

Mais la petite ville de la Roche-Bernard a aussi amélioré son traitement
des eaux  (ce qui a été bénéfique pour la propreté des eaux des plages de
Damgan dans le Morbihan, mais aussi des marais salants classés de
Guérande): cette baie de Vilaine est cernée de parcs naturels sur le
continent, et protégée des courants Atlantiques par Quiberon, Belle-Île et
le flux d'eau douce venant de la Loire, l'eau douce de la Vilaine et des se
répand en surface dans la baie et touche ses plages continentales plus que
ne le fait l'eau atlantique plus dense, et la marée remue plus l'eau douce
qu'elle ne ramène d'eaux atlantiques. Le vent d'ouest tend aussi à étaler
les eaux fluviales le long des côtes continentales au plus près des plages,
mais protège Belle-Île, Quiberon et le Golfe du Morbihan.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] ligne de bus : tag network

[marc marc]

Le 22/08/2017 à 21:47, Noémie Lehuby a écrit :
 > On veut indiquer que les lignes (relations route_master)
 > et les parcours (relation route) appartiennent à un réseau.
 > On peut donc :
 > 1) mettre le nom du réseau sur les relations : tag network =
 > TransHauteGaronne
 > 2) mettre un identifiant quelconque de réseau sur les relations :
 > tag network : fr_arc_en_ciel
 > 3) mettre un identifiant wikidata sur les relations :
 > tag network:wikidata = Q-whatever
 > 4) regrouper les relations dans une relation network TransHauteGaronne

 > Je n'ai rien contre 3 et 4 tant qu'on les combine avec 1.
 > La seule qui m'embête c'est la 2. Car elle crée une ambiguité sur ce
 >> qu'on trouve dans le tag network.
 >> A minima, mettons un tag network_id mais pas network.
très bon résumé

mais au lieu de créer un nouveau tag,
- ne pourrait-on pas utiliser network:wikidata s'il existe
- et pour ceux qui n'en ont pas, suivre la logique du tag ref avec 
quelque chose genre network:ref ou ref:FR:network:bus ?
Ou si c'est plus pratique une seule clef pour les 2 cas,
on crée une ref pour tout réseau, une sorte de wikidata version osm
une page wiki où on ajoute chaque nouvel identifiant et ca roule.

Le 22. 08. 17 à 22:52, Philippe Verdy a écrit :
 > les applications qui ont commencé à utiliser network=*
 > ont supposé que le nom indiqué derrière était unique
un exemple d'une app affectée ?
Si on a une clef unique pour identifier tout un réseau, où est le 
problème ? une sélection overpass et tous les noms sont unifiés.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OSM à la plage;-) . Était : le festival de tout les highway :-)

[Christian Rogel]

> Le 2017 Eost 22 à 17:45, Philippe Verdy  a écrit :
> 
>> 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)
> 
> Sûrement pas le mannois (Île de Man) qui est une langue Q-celtique apparenté 
> à l’irlandais et au gaéique écossais.
> 
> Justement si avec le mannois (à l'oral dans leurs forme vernaculaire). C'est 
> connu par les témoignages écrits (en français ou anglais) rapportés de 
> pêcheurs et des commerçants dans les ports, et des écrits paroissiaux, 
> notariés, des actes de justice, des voyageurs, et dans les armées, les 
> anciens pêcheurs du Guilvinec dans les années 1970 témoignaient encore 
> eux-mêmes de leur expérience ou celle de leurs parents, quand ils prenaient 
> abris dans les ports des uns et des autres en cas de gros temps, fréquent en 
> mer d'Irlande et mer d'Iroise, ou se portaient secours entre eux : c'était 
> alors très facile d'échanger en breton et mannois plutôt qu'en français ou 
> anglais dont ils ne comprenaient que des bribes.
> 

Réponse courte : ne pas parler d’intercomprèhension, quand il ne s’agit que 
d’échanges dans un registre limité : dans celui de la mer, beaucoup de mots 
très proches et interceltiques, mais, pas les articulations syntaxiques.
Un peu comme les occitanophones peuvent échanger avec les Piémontais.
Moi-aussi, Jean-Yvon je comprend parfois  le sens général d’un texte en 
gallois, et il me suffirait d’un peu de pratique orale ou écrite, mais, s'il y 
a beaucoup de mots communs entre breton et gallois, il y en a beaucoup moins 
avec les langues gaéliques.
Certains rêvent de bâtir une koinè celtique.

> 
> Même encore aujourd'hui l'orthographe bretonne a plusieurs écoles, avec le 
> vannetais qui se distingue des 3 autres principales formes dialectales, et 
> donc deux orthographes encore en compétition (il y en a eu plus dans le 
> passé), et il reste des désaccords sur l'emploi ou non des diacritiques pour 
> tenter d'unifier et reconnaître les formes dialectales (les vannetais ne sont 
> pas satisfaits du fait que la norme oublie de différencier des phonologies 
> qu'ils considèrent comme clairement distinctes et des auteurs vannetais 
> dévient volontairement de la norme développée par l'office de la langue 
> bretonne ou inisste pour qu'on y ajoute des termes vannetais qui leurs sont 
> propres pour enrichir le vocabulaire commun au lieu de le réduire à une forme 
> dominante).

L’Office public de la langue bretonne utilise l’orthographe normalisée de 
l’enseignement, car, il en faut bien une. Cependant, le breton avec des 
vannetismes est admis et encouragé par les revues littéraires et j’en vois 
souvent.
Les querelles orthographiques sont éteintes, faute de combattants. La seule 
maison d'édition « non-alignée » a déposé son bilan.

Tout ceci nous emmène loin d’OSM.


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

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

[Richard]

On Tue, Aug 22, 2017 at 05:24:02PM +0100, Lester Caine wrote:
> On 22/08/17 17:19, Philip Barnes wrote:
> >> called differently, but this is it:
> >> https://wiki.openstreetmap.org/wiki/Key:maxspeed:practical
> >>
> > Isn"t that going to be rather subjective?
> 
> And will depend on 'time of day' ;)

of course - and you can use condiotional descriptions to map this.

Richard

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

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

[Richard]

On Tue, Aug 22, 2017 at 10:00:07PM +0200, Martin Koppenhoefer wrote:
> 
> 
> sent from a phone
> 
> > On 22. Aug 2017, at 15:46, Richard  wrote:
> > 
> > called differently, but this is it:
> > https://wiki.openstreetmap.org/wiki/Key:maxspeed:practical
> 
> 
> yes, but practical maxspeed depends a lot on your equipment and capabilities, 
> and on other people driving in front of you, so this tag will probably not be 
> very uniform around the globe. Also, some people are willing to risk a 
> speeding ticket, others don't. With regard to the latter, the situation in 
> Italy is particularly ridiculous: the authorities have to sign post speed 
> controls ;-) i.e. speeding tickets are kind of rare.

maxspeed:practical should take dense account or traffic jams into 
account as good as possible. So far I am not aware of any router
evaluating time based conditional restrictions but those could be
used to take rush hours somewhat into account.

maxspeed:practical should not have any values above the legal speed
limit.. and if it had routers should ignore such values anyway, at 
least thats what I would expect from navigation software.
Many years ago something like this was encouraged in the ancient 
proposal but it is no longer in the description.. if there is any 
remaining doubt I would explicitly state it in the wiki.

Richard

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

Re: [OSM-talk] Macromapping problems

[Daniel Koć]

W dniu 22.08.2017 o 22:29, Martin Koppenhoefer pisze:

it's not easy for forests or similar things either, because they might be split 
(for good reason) into several smaller objects. What you need for good macro 
maps is generalization, i.e. merging together of similar things, reduction of 
unwanted detail while keeping the characteristics and significant features and 
shapes. Nothing we should encourage our mappers to do in the main db (at least 
as long as we have one scale fits it all data), it must be done parallel or 
with locally processed data.


In Europe (but also in Japan, India and in Canada) there are many 
smaller forests, not just one big woodland, and you can still see them 
as a big area (see for example French style), so I don't think we would 
need generalization in other parts of the world too.


Sahara not only doesn't have a name in OSM, but it's also evident for me 
that most of its parts are missing. Even if French style shows 
natural=desert and not natural=sand (on the osm-carto we do the other 
way around), both types combined are far from covering the whole area.


--
"Probably it's an eternal problem - too many chiefs, too few Indians" [O. 
Muzalyev]


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

[OSM-ja] State of the Map2017 in Aizuwakamatsu開催報告と御礼

[jun meguro]

State of the Map2017 in Aizuwakamatsu実行委員会代表の目黒です。

去る8月18日から20日にかけて、State of the Map2017 in Aizuwakamatsu（以下SOTM）が開催されました。

概算ではありますが、来場者数は200名、3日間のべ参加者数は550名に登り、交通面での不利をものともしない盛大な規模となりました。（この他、スタッフボランティア参加38名、発表41件、ライトニングトーク16件、ワークショップ10件、県立博物館オプショナルツアー37名）

また今回のSOTMは通算10回目の開催というだけでなく、過去に例のない同一国での2回目の開催という快挙でもありました。

世界30カ国から集った参加者は、カンファレンスで知識を共有し、史跡鶴ケ城で歴史に触れ、そしてコミュニケーションを更に深めた後、再び各々のホームグラウンドへと戻っていきました。

開催にあたり、地元福島のローカルコミュニティをはじめ、OSM-FJの皆さんと、またOSMに携わる全国・全世界のコミュニティの協力を頂きました。

この中の誰が欠けても同じクオリティを作り上げることは難しく、最高のメンバーとコミュニティによって継続されてきた活動の、ひとつの結実であったと感じています。

ここ数日胸に去来するのは、大きな達成感と、また裏腹の物寂しい喪失感であるかも知れません。
しかし我々マッパーが満たすべき空隙は広く、胸中に火点が灯るのはすぐさまの事だろうと思います。

昨年の今頃、我々が感じていた不安と熱はいま、ミラノへ移りました。
遠い友人達と再び相まみえるまで、手足が届く限りの空間を、今はマッピングして行きましょう。

あらためて皆様、ご協力ありがとうございました。
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

[François Lacombe]

Bonsoir à tous,


Le 21 août 2017 à 23:21, marc marc  a écrit :

> si tu les connais, préviens les qu'ils ne réagissent pas ici.
>

C'est fait ici : https://twitter.com/InfosReseaux/status/899711313781436420


>
> il est vrai que la proposition concerne aussi le tag flow_capacity
> ce n'est pas la même chose que si la proposition n'en parlait pas.
> Donc en effet autant voter sur quelque chose d'abouti.
> Mais voilà, je ne vois pas exactement le problème avec flow_capacity
> capacity:flow je trouve flow assez générique. vois-tu un autre tag avec
> flow possible ? parce que sinon c'est un peu l'inverse de type, ce serra
> un tag tellement précis qu'il n'existe qu'avec capacity et dans ce cas
> flow_capacity serrait tout aussi bien.
> Si t'as un exemple d'autre "flow", je me rangerai à ton avis.
>

Je suis ok pour dire que ce n'est que de la forme et je n'ai pas trouvé
d'autre clé qui puisse aller avec flow.
N'ajoutant dans OSM que des données statiques, il ne peut s'agir que d'une
capacité.

Le seul argument est que capacity existe, qu'on peut l'exploiter et il
était intéressant de regrouper la capacité en débit et en connexions sous
la même clé
Un peu comme ref=*, qui est un bon exemple : tout ce qu'il traite ne peut
être que des références, pourtant on l'a bien segmenté pour des raisons
évidentes de documentation et de collisions.
On a pas fait de INSEE_ref, mais ref:FR:INSEE ou de erdf_ref mais
ref:erdf:gdo, etc...


pourquoi rajouter un nouveau tag à discuter ? la proposition ne touche
> pas à ce tag, c'était mauvais, cela reste mauvais, cela reste à
> améliorer. sinon au final on se trouve avec une propal pour résoudre
> tous les défaut d'osm (je caricature volontairement fortement) mais qui
> reste non adoptée.
>
Parce que c'est dans le sujet traité et que le temps manque aussi.
Là on est quand même assez raisonnable je trouve :)
Et même en ajoutant deux tags, on est loin de tout avoir traité. Il restera
bien quelques propositions à faire avant d'avoir un modèle complet. Tout
l'aspect des connexions (hormis les clés coupling) n'est pas traité et là
je suis d'accord de ne pas le faire car c'est vaste.


> > Ne pas discuter des points pour accélérer ne m'attire pas trop.
> mon avis n'est pas dans ce sens.
> je voulais dire "diviser pour aboutir", un pas après l'autre
>
C'est quand même ce que nous faisons, la description est pas encore
complète et ne le sera pas à l'issue du vote de cette proposition
Meme en ajoutant les deux clés sous capacity.

Je te laisse le mot de la fin ayant donné toutes mes billes sur le sujet
pour voir ce qu'on fait remonter à Viking :)


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

Re: [OSM-talk] Macromapping problems

[Daniel Koć]

W dniu 22.08.2017 o 19:59, Oleksiy Muzalyev pisze:

In fact I am working on a project in this field. I am mapping landuse 
of the South Ukraine http://www.openstreetmap.org/#map=10/46.9634/31.5143


This is what I consider to be midzoom. You can see it here (and soon 
also on z8+on default map):


http://tile.openstreetmap.fr/?zoom=8=47.67465=32.03586=B00FF

but not on z3 for example.

--
"Probably it's an eternal problem - too many chiefs, too few Indians" [O. 
Muzalyev]


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

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[Philippe Verdy]

L'ennui c'et que toutes les applications qui ont commencé à utiliser
network=* ont supposé que le nom indiqué derrière était unique, ce qu'il
n'est pas. En fait ils voulaient que ce soit bien un identifiant.

Comme cet identifiant rendu unique ne correspond pas au nom qu'on voudrait
donner aux utilisateurs (lequel nom peut aussi avoir plusieurs traductions
co-officielles dans des pays multilingues) et qui n'est pas unique non plus.

Bref rendre unique network=* en utilisant des préfixes ou suffixes (et si
possible le préfixe "FR:" selon la convention des préfixes de pays, et non
"fr_" comme on le voit, mais cela peut ne pas suffire encore pour les
homonymies propres au même pays, et là on peut utiliser un autre préfixe ou
suffise après le "FR:").

Reste à savoir où mettre le(s) nom(s) du réseau et ses autres informations
: c'est là que la relation type=network est tout à fait appropriée pour ne
pas avoir à dupliquer ça dans tous les objets qui vont en devenir membre.
On y mettre les adresses de site web d'information, les adresses de
contact, numéros de téléphone, identifiant wikidata (et tout ce qui
semblera approprié, y compris les contacts de réseaux sociaux, ou des
identifiants spécialisés pour applications mobiles ou jeux de données
utilisables, ou encore une URL de logo).

De coup plus besoin d'aucun tag sur les objets membres

Mais par compatibilité on gardera encore un "network=" (le même que
celui dans la relation type=network, que toutes les applis n'utiliseront
pas) au minimum sur les relations "type=route" (cela concerne surtout les
applis basées sur l'ancienne v1 du schéma public transport, qui ne
connaissaient pas non plus les relations "route_master", les "super_route"
des lignes segmentées en plusieurs parties, les "stop_area", et ne
connaissaient pas autre chose que les noeuds "bus_stop" en fait utilisés
alors pour les plateformes soit pour les arrêts ou "railway=halt" et
"railway=station"). Mais on sait que ces applis auront des problèmes à
gérer les homonymies inattendues si "network=" n'est pas unique, et on
a intérêt à ce que cet  soit quand même relativement lisible par un
humain (même s'il est monolingue et a des affixes de désambiguisation) :
ces applications apprendront plus tard à afficher un meilleur nom
(éventuellement localisé pour plusieurs langues), soit à partir de la
relation "type=network" ayant le "même network=", soit à partir de la
liste des relations parentes.

Note: "network=" est parfois rendu unique en l'associant à "operator=*"
(c'est nécessaire sur certains réseaux ayant plusieurs opérateurs
exploitants des lignes homonymes avec la même "ref=*". Ce cas est rare et
ne devrait pas exister en France où chaque réseau dispose d'un opérateur
principal (les autres opérateurs sont des fournisseurs et peuvent mettre à
disposition des lignes ou tronçons de lignes, et c'est en fait le couple
"operator"+"ref" qui identifie la ligne sur le réseau "network=". Je
pense que cela concerne surtout l'Allemagne, peut-être aussi la Suisse ou
la Belgique.

Mais je vois des cas d'homonymies de "network=*" apparaître aux Etats-Unis
entre différents Etats, ou même avec des réseaux d'autres pays
(Philippines, Indonésie, Canada) et même avec des réseaux européens.
Jusqu'à présent on se souciait peu de ça car les réseaux de transport sont
largement à développer un peu partout. Je ne serais pas surpris de voir des
tas d'homonymies en Afrique.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[lenny.libre]

Le 22/08/2017 à 21:47, Noémie Lehuby a écrit :

Hello,

Si je peux me permettre un petit résumé intermédiaire :
On veut indiquer que les lignes (relations route_master) et les 
parcours (relation route) appartiennent à un réseau. Je laisse de côté 
pour le moment l'autre sujet sur le réseau sur d'autres objets.

Je reprends mon exemple fictif de Arc-En-Ciel renommé TransHauteGaronne.

On peut donc :
1) mettre le nom du réseau sur les relations : tag network = 
TransHauteGaronne
2) mettre un identifiant quelconque de réseau sur les relations : tag 
network : fr_arc_en_ciel
3) mettre un identifiant wikidata sur les relations : tag 
network:wikidata = Q-whatever

4) regrouper les relations dans une relation network TransHauteGaronne

Et bien sur, on peut combiner, puisqu'apparemment :
vers Toulouse, on fait 2 et 4
vers Tours et Nantes par exemple (pour reprendre des exemples cités 
ici), on fait 1 et 4


Personnellement, je m'en tiens à 1.
Et oui, il y a un travail de maintenance et d'uniformisation des tags 
network. Mais bon par rapport à la complexité de la maintenance 
globale des données de transport, uniformiser les noms des réseaux, ce 
n'est vraiment pas la partie qui est longue ou difficile, au contraire.


Je n'ai rien contre 3 et 4 tant qu'on les combine avec 1.
La seule qui m'embête c'est la 2. Car elle crée une ambiguité sur ce 
qu'on trouve dans le tag network.

A minima, mettons un tag network_id mais pas network.

Noémie
avec comme l'a dit Christian (si je n'interprète pas ce qu'il a dit) 
"Les name (pourquoi pas network:name) sont destinés à des humains... les 
deux se complètent et pour l'instant network=* fait (mal) un peu les deux. "


leni

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

Re: [OSM-talk-fr] OSM à la plage;-) - rendu des côtes osm et osm-fr

[osm . sanspourriel]

Aparté : /une personne achète un journal en Gallois, le patron lui fait 
remarquer qu'il n'a pas acheté un journal en anglais mais en gallois. 
Cette personne lui traduit donc un article et lui explique que 
bretonnant il lit mieux le gallois que l'anglais./


C'est plus bizarre que ça pour le rendu (qui n'a pas sa liste spéciale, 
même pas pour le rendu francophone ! :-D).


Le rendu français montre les noms des îles/ilots dès le niveau 12 
. Curieusement au 
niveau 14 
 
ils disparaissent.


Pour le rendu standard il faut attendre le niveau 14 
.
Les place 
=islet 
 comme 
Enez Vian 
 
le bien nommé (la "petite île" en breton) n'apparaissent jamais.
Testé 
 
dans pas mal de rendus et mauvais car on risque d'inciter à taguer pour 
le rendu.


Allez tant qu'à être dans le coin et parler de traduction : d'une 
manière générale je préfère les noms en langue locale (donc en breton 
ici) mais pour Ar Men Gast il vaut mieux prévenir les navigateurs que le 
coin est dangereux. Ces rochers ce sont Les Putains en français.

Christian, tu peux entrer ces toponymes dans OSM.

/Philippe, je parlait de la couleur de la Vilaine, au niveau du tuyau 
surmonté d'une surface gravillonnée, j'ai du mal à penser à de belles 
vallées à côté/.


Jean-Yvon

Le 22/08/2017 à 16:33, Christian Rogel - 
christian.ro...@club-internet.fr a écrit :


Le 2017 Eost 21 à 23:51, Philippe Verdy > a écrit :




 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



Vrai, on a un texte (lexique de médecin herboriste) qui daté du milieu 
du 9ème. Il est « armoricain » pour les fioritures de son écriture, 
mais, on écrivait la même langue des deux côtés de la Manche jusqu’au 
11ème.


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)


Sûrement pas le mannois (Île de Man) qui est une langue Q-celtique 
apparenté à l’irlandais et au gaéique écossais. Pas avec le gallois, 
non plus, depuis le Haut Moyen-Âge. L’intercompréhension a du être 
possible avec le cornique jusqu’à la Rennaissance, au cours de 
laquelle il s’éteint.
Me promenant en Cornouaille, je comprenais certains noms de lieu et 
les numéros donnés en lettres.


Ex : D. du Maurier a écrit « The House on the Strand », ce qui est la 
traduction du nom d’un village, Tywardreath 
  lequel existe encore au bord d’un 
ancien estuaire maintenant comblé. Un brittophone n’a pas besoin de 
traduction, car il écrirait  « Ti war draezh » (ou Tiwardraezh) et 
prononcerait « Ti war drêz » .


Ceci m’amène à traiter la question du tagging des rivages complexes, 
rocheux ou sableux.  On a édité une série de 12 livres en breton sur 
les noms des côtes du Nord-Finistère. Pour deux communes, 
Ploudalmézeau et Lampaul-Ploudalmézeau, ce n’est pas moins de 700 
toponymes qui ont été recueillis auprés des pêcheurs et ds goémoniers.
Tout avait un nom, rocher en mer et sur les dunes, passages entre 
rochers à marée, une île pouvait avoir chacun de ses faces nommées 
(Fri Karn et Skoaz Karn faisant allusion au « nez et à « l’épaule ») 
pour l’Ïle Carn.


Un constat : les caps et les rochers isolés ne sont pas dans le rendu 
OSM standard.



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] Macromapping problems

[Martin Koppenhoefer]

sent from a phone

> On 22. Aug 2017, at 01:42, Daniel Koć  wrote:
> 
> Of course we can have some of them, but while landuses can be added quite 
> easily, it's different with the rest.


it's not easy for forests or similar things either, because they might be split 
(for good reason) into several smaller objects. What you need for good macro 
maps is generalization, i.e. merging together of similar things, reduction of 
unwanted detail while keeping the characteristics and significant features and 
shapes. Nothing we should encourage our mappers to do in the main db (at least 
as long as we have one scale fits it all data), it must be done parallel or 
with locally processed data.

Cheers,
Martin 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Lester Caine]

On 22/08/17 20:45, Martin Koppenhoefer wrote:
> Generally it might be interesting to add a preference to routing engines 
> ("I'll be going 20 more than allowed where possible")?
Actually that is a niggle with OSMAND ... it only allows a fixed over
speed amount before warning ... what it should be using is a percentage,
so 5% would be tidy and 10% pushing where a traffic camera would be
'within tolerance'. Since speedometers are only required to be 'within
10%' currently ... you get the idea ;)

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

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

[Martin Koppenhoefer]

sent from a phone

> On 22. Aug 2017, at 15:46, Richard  wrote:
> 
> called differently, but this is it:
> https://wiki.openstreetmap.org/wiki/Key:maxspeed:practical


yes, but practical maxspeed depends a lot on your equipment and capabilities, 
and on other people driving in front of you, so this tag will probably not be 
very uniform around the globe. Also, some people are willing to risk a speeding 
ticket, others don't. With regard to the latter, the situation in Italy is 
particularly ridiculous: the authorities have to sign post speed controls ;-) 
i.e. speeding tickets are kind of rare.


cheers,
Martin 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[Noémie Lehuby]

Hello,

Si je peux me permettre un petit résumé intermédiaire :
On veut indiquer que les lignes (relations route_master) et les parcours 
(relation route) appartiennent à un réseau. Je laisse de côté pour le 
moment l'autre sujet sur le réseau sur d'autres objets.

Je reprends mon exemple fictif de Arc-En-Ciel renommé TransHauteGaronne.

On peut donc :
1) mettre le nom du réseau sur les relations : tag network = 
TransHauteGaronne
2) mettre un identifiant quelconque de réseau sur les relations : tag 
network : fr_arc_en_ciel
3) mettre un identifiant wikidata sur les relations : tag 
network:wikidata = Q-whatever

4) regrouper les relations dans une relation network TransHauteGaronne

Et bien sur, on peut combiner, puisqu'apparemment :
vers Toulouse, on fait 2 et 4
vers Tours et Nantes par exemple (pour reprendre des exemples cités 
ici), on fait 1 et 4


Personnellement, je m'en tiens à 1.
Et oui, il y a un travail de maintenance et d'uniformisation des tags 
network. Mais bon par rapport à la complexité de la maintenance globale 
des données de transport, uniformiser les noms des réseaux, ce n'est 
vraiment pas la partie qui est longue ou difficile, au contraire.


Je n'ai rien contre 3 et 4 tant qu'on les combine avec 1.
La seule qui m'embête c'est la 2. Car elle crée une ambiguité sur ce 
qu'on trouve dans le tag network.

A minima, mettons un tag network_id mais pas network.

Noémie


Le 21/08/2017 à 20:28, lenny.libre a écrit :
Entre les deux mon cœur balance, au fur et à mesure de ce que je lis, 
je change ... Je n'avais pas d'avis au départ, mais maintenant je n'en 
ai pas plus.


Le 21/08/2017 à 02:05, Jérôme Amagat a écrit :
Je rappelles que les relations network n'est sur le wiki qu'a l’état 
de proposition, que cette proposition date de 2008, que rien n'a 
bougé sur cette proposition depuis 2013 (et plus après 2009 ce n'est 
que pour ajouté des exemples). Il y a des ajouts sur la page de 
discutions un peu plus récent 2014 mais il sont négatif a l'ajout de 
ces relations.


Cette relation, ça serait juste, mettre tous les éléments qui ont le 
même tag network=* dans une même relation (ou que les 
type=route_master) donc c'est faire une liste, une catégorie ce qui 
ne se fait pas dans osm. Si l'on veux tous les élément d'un même 
réseau il y a d'autre moyen de les obtenir que de créer ce type de 
relation. Si c'est pour pouvoir mettre quelque part le vrai nom du 
réseau pourquoi ne pas le mettre directement dans le tag network=*.
Le principal avantage que je vois dans la relation c'est ce qu'il m'a 
semblé comprendre de ce disait Philippe : le tag "network", c'est 
uniquement un code donc au lieu de fr_tisseo on pourrait avoir 
FR:pt_tlse - dans la relation, on peut aussi y mettre wikidata pour 
avoir l'unicité) le jour ou le nom du réseau change, il suffirait de 
changer le name (et éventuellement le wikidata) dans la relation 
network ; il y a quelques temps à Bordeaux (où il n'y a pas de 
relation network), tous les tags "network" on été modifiés de "TBC" -> 
"TBM".


Le wikidata qui me plaisait (en permettant avec osmose de contrôler) 
m'a un peu refroidi depuis que je vois qu'il y a des manques de 
rigueur et que si le nom change, il faudra certainement changer le 
network et aussi le network:wikidata, j'y vois moins d'avantages, la 
marque du réseau de Bordeaux étant passé par le stade CGFTE 
(wikidata=Q2990197) je n'ai pas trouvé TBC, puis TBM 
(wikidata=Q377695)  et comment je fais pour le réseau du transport 
scolaire de Haut-Garonne qui n'a pas de wikidata ?


Si vous pensez que ces relation doivent exister, remettez un peu a 
jour la page de proposition avec des exemples qui existent encore et 
allez parler d'un vote de cette proposition sur la liste tagging (en 
anglais :) ) .


Sinon pourquoi ne pas créer des relations pour tous les objets qui 
ont le même operator comme par exemple EDF et vu que le même nom 
pourrait être utilisé ailleurs dans le monde il faudrait pour tout 
les tag operator=* ajouter "fr_" devant le nom comme par exemple 
operator=fr_EDF.
C'est que la relation ne serait pas utilisée pour faire la liste de 
tous les objets (bâtiment, parkings, agences, ...) ce qui serait une 
catégorie, mais uniquement les éléments constitutifs du réseau.
Après avoir beaucoup écouté, fr_ (qui est associé à la langue) ne 
devrait pas être utilisé, mais plutôt FR: (associé au pays)


Pareil pour les nom de rue addr:street=*, par exemple, il faudrait 
différencier l'"Avenue du général de Gaulle" des différentes villes, 
c'est pas les mêmes. On fait quoi on préfixe avec le nom des ville? 
De toute façon les noms on les mets que sur le tag name=* donc il n'a 
pas à être sur addr:street=* donc on peut y mettre quelque chose qui 
servira de référence pour chaque rue différente dans le monde. et on 
crée une relation pour chaque rue où on met dans name=* le vrai nom 
de la rue. A mer**, ça existe déjà, c'est les relation 
associatedStreet mais là on n'a pas modifié ce qu'on met dans 

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

[Martin Koppenhoefer]

sent from a phone

> On 22. Aug 2017, at 14:40, Greg Troxel  wrote:
> 
> Another is in the US
>  where there are many roads signed 65 mph where traffic normally moves
>  at 80 mph.


80mph are 129kph, so I guess these are motorways or bigger roads?
Maybe this should be fixed by the legislator rather than in osm? If everybody 
is ignoring a specific law and it doesn't harm others, maybe the law has to be 
updated? ;-)


Generally it might be interesting to add a preference to routing engines ("I'll 
be going 20 more than allowed where possible")?

cheers,
Martin 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[marc marc]

Le 22. 08. 17 à 20:32, lenny.libre a écrit :
> Le 20/08/2017 à 12:02, marc marc a écrit :
>>> - _"public_transport=platform"_ il me semble que les tags "network"
>>> sont nécessaires, surtout lorsque l'objet n'est pas encore membre d'une
>>> relation "route" ou "public_transport=stop_area"
>> ce n'est pas "pas utile", c'est erroné que de dire qu'un trottoir ou un
>> abribus fait partir d'un réseau de transport en commun. c'est du
>> mobilier urbain. sinon à ce rythme là, on pourrait aussi ajouter les
>> routes, les carrefours, les lampes qui éclairent la route, la station
>> d'essence où le bus fait le plein, ...
> que veux-tu dire ?
>  - ce n'est pas "pas utile" : c'est-à-dire que c'est utile (double 
> négation) - ou - ce n'est pas "mais, alors vraiment pas utile" ?

Je reformule :
utile ou pas, mettre le tag operator et network du réseau de bus est erroné
sur les objets physiques (plateform, stop_position).
Pour preuve, les valeurs "operateur1;operateur2" qu'on rencontre alors 
qu'il n'y a qu'un opérateur en charge du mobilier urbain et de la route.

> parles-tu des éléments physiques ou du node qui représente l'arrêt ?
Je parle des éléments physique y compris le node de l'arrêt indiquant 
l'emplacement physique du plateform.

Les relation route_bus et master_route sont fait pour décrire 
l'utilisation de ces objets par les compagnies de bus.
C'est sur ces éléments qu'il faut mettre les tag du réseau de bus.
et aussi sur le stop_area vu que la schéma PT v2 a été voté ainsi.

 >>> lorsque l'objet n'est pas encore membre d'une
 >>> relation "route" ou "public_transport=stop_area"
on peux utilement mettre fixme=rajouter au stop_area
ou fixme=ajouter ligne de bus 42
ainsi c'est clairement visible ce qu'il reste à faire
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Martin Koppenhoefer]

sent from a phone

> On 22. Aug 2017, at 13:29, Colin Smale  wrote:
> 
> I don't understand why junction penalties should be dependent on the road 
> classes, and not on physical characteristics. I guess this is just a 
> heuristic which can be useful if you don't have the full picture.
> 


often on junctions passing on the higher road will be advantageous compared to 
approaching via lower roads (which typically have to give way, or will have 
shorter green light, etc.). That's the classic situation which is probably the 
reason that higher rated roads are preferred by routing engines.

It is of course a generalization, and in other (probably much fewer) cases, the 
main road might have always green light but the other roads will get green 
light when a car is approaching (induction loops, etc.). When the junction is a 
roundabout the road class won't matter. It's really complex to get "the full 
picture" of all real world constellations that do exist, even more with 
technology interacting with traffic lights, ideally you would have to have real 
time information about other vehicles and about traffic light states in order 
to choose the current best solution (even better would be predicting the 
traffic for the time when you will be there, surely quite complex task). 

I don't say prioritizing bigger highway classes is the absolutely best thing to 
do, but it's probably for most cases a good solution and far less complicated 
to calculate.

cheers,
Martin ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Proposition tag voie verte

[marc marc]

Bonsoir,

je suis tout a fait d'accord avec les tags
Highway=path
foot=designated
bicycle=designated

Par contre je ne comprend pas l'utilité d'ajouter systématiquement 
motor_vehicle=no puisqu'un path est déjà interdit aux véhicules motorisé 
tel qu'indiqué sur sa page wiki et sur la page des valeurs par défaut
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#France

Pour les voie verte où une barrière bloque l'accès physique aux 
véhicules d'urgences, par harmonie avec les autres voies, ne serrait-il 
pas préférable d'ajouter une noeud barrière avec motor_vehicle=no ?
cela n’empêche pas un véhicule d'urgence d'avoir éventuellement une 
autre entrée ailleurs. et surtout ce n'est qu'à faire s'il y une 
barrière, pas systématiquement sur toutes les voies vertes.

Cordialement,
Marc

Le 21. 07. 17 à 10:01, RAOULT Emmanuel a écrit :
> Bonjour,
> 
> 
> J'ai modifié le wiki de Montpellier en conséquence : 
> https://wiki.openstreetmap.org/wiki/Montpellier#Cyclabilité
> Si cela vous convient et que nous restons sur ce format, il pourra être 
> intéressant d'ici quelques semaines de le remonter dans le wiki national 
> pour les vélos, rubrique voie verte ...
> Bonne journée,
> 
> Emmanuel RAOULT
> 
> Chargé d’Opération Déplacements
> 
> Montpellier Med 
>   
> 
> /*Direction des Mobilités* - *Service Gestion Multimodale des 
> Déplacements***/
> 
> /*
> */
> 
> /1 place Georges Frêche - Montpellier/
> 
> /Téléphone : 04-67-34-72-43/
> 
> /e-mail : e.rao...@montpellier3m.fr /
> 
> 
> 
> *De: *"Romain MEHUT" 
> *À: *"Groupe OSM Montpellier local-herault" 
> 
> *Envoyé: *Jeudi 20 Juillet 2017 22:42:27
> *Objet: *Re: [local-herault] Proposition tag voie verte
> 
> Bonjour,
> 
> Les tags que tu proposes sont effectivement ceux qui sont indiqués dans 
> ce cas de figure.
> 
> Trois exemples de discussions sur le sujet 
> https://lists.openstreetmap.org/pipermail/talk-fr/2014-March/066953.html 
> et 
> http://talk-fr.openstreetmap.narkive.com/0hlF2Csi/osm-talk-fr-classement-national-regional-local-des-pistes-cyclables
>  
> et http://gis.19327.n8.nabble.com/path-cycleway-et-footway-td5876181.html
> 
> Romain
> 
> Le 20 juillet 2017 à 18:35, RAOULT Emmanuel  > a écrit :
> 
> Bonjour,
> 
> 
> Nous rencontrons des difficultés pour identifier facilement les
> voies vertes. En plus du tag highway=path suggéré par le wiki vélo
> d'OSM, je vous propose de rajouter bicycle=designated et
> foot=designated (horse=designated étant en option) ... en plus des
> tags optionnels surface=* et width=* ...
> Qu'en pensez-vous ?
> Est-ce que certains d'entre vous a vu passer des discussions sur les
> voies vertes pour OSM ?
> Bonne journée et merci d'avance pour vos contributions,
> 
> Emmanuel RAOULT
> 
> Chargé d’Opération Déplacements
> 
> Montpellier Med 
>   
> 
> /*Direction des Mobilités* - *Service Gestion Multimodale des
> Déplacements***/
> 
> /*
> */
> 
> /1 place Georges Frêche - Montpellier/
> 
> /Téléphone : 04-67-34-72-43/
> 
> /e-mail : e.rao...@montpellier3m.fr /
> 
> 
> 

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

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[lenny.libre]

Le 20/08/2017 à 12:02, marc marc a écrit :

  - _"public_transport=platform"_ il me semble que les tags "network"
sont nécessaires, surtout lorsque l'objet n'est pas encore membre d'une
relation "route" ou "public_transport=stop_area"

ce n'est pas "pas utile", c'est erroné que de dire qu'un trottoir ou un
abribus fait partir d'un réseau de transport en commun. c'est du
mobilier urbain. sinon à ce rythme là, on pourrait aussi ajouter les
routes, les carrefours, les lampes qui éclairent la route, la station
d'essence où le bus fait le plein, ...

que veux-tu dire ?
    - ce n'est pas "pas utile" : c'est-à-dire que c'est utile (double 
négation) - ou - ce n'est pas "mais, alors vraiment pas utile" ?


parles-tu des éléments physiques ou du node qui représente l'arrêt ?


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

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[lenny.libre]

ä la base,la discussion avait commencé parce que pour le réseau arc en
ciel, le nom même du réseau est très hétéroclite et de plus 2 réseaux
différents semblent exister en France avec ce nom.
il aurait été pratique d'avoir 2 relations pour permettre au moins de
classer les objets dans le bon groupe même si la typo exact du nom doit
être affinée (celui de leur site web, celui écrit sur les bus, ..)
le réseau Arc-en-Ciel de Haute-Garonne a une relation network 
https://www.openstreetmap.org/relation/1546978

Mais puisqu'il est mieux de faire sans relation network, le débat est
rouvert sur comment les séparer facilement.
___
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] Macromapping problems

[Oleksiy Muzalyev]

On 22.08.17 18:43, Daniel Koć wrote:

W dniu 22.08.2017 o 08:38, Oleksiy Muzalyev pisze:
Irkutsk Oblast has got an area larger than the area of say Germany, 
California, or France. The nature, woods, rivers, lakes, etc. there 
is amazing. It is one of the most beautiful regions of the planet.


Actually the whole territory at and around this node is coniferous 
forest which is not mapped yet, and that is why also not visible on 
the macro-map.


This is exactly what bothers me with macro scale - there are really 
big areas on the planet which are not mapped yet and we have just 
plain land color there as if there was nothing. Irkutsk is just one of 
them.


Continent tagging as a node is just a workaround, because we don't 
know how to do it better. But with forest it should be easy already 
(we know how to do it properly, just nobody did it yet). I'm also yet 
to see big Eurasian Steppe belt 
(https://en.wikipedia.org/wiki/Eurasian_Steppe) or any other steppe 
around the world 
(https://commons.wikimedia.org/wiki/File:Steppe_world.png) and we have 
"grassland" tag for this probably.


If something like this can be done with current tools, but it's not, 
means to me that we don't care for macro scale at the moment. That's 
why I try to bring the subject to the table.


In fact I am working on a project in this field. I am mapping landuse of 
the South Ukraine http://www.openstreetmap.org/#map=10/46.9634/31.5143


I would like to see how much landuse one mapper can cover. Now when 
there is the DigitalGlobe satellite imagery with good resolution and 
coverage, quality displays, it becomes realistic to map all the landuse. 
I map South Ukraine landuse manually in JOSM, no imports.


In the past in Siberia there was little satellite coverage, nowadays I 
see that it changed too. I do not know why they do not map forests 
there. Probably it's an eternal problem - too many chiefs, too few Indians.


Best regards,

Oleksiy


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

Re: [OSM-talk] Macromapping problems

[Daniel Koć]

W dniu 22.08.2017 o 08:38, Oleksiy Muzalyev pisze:
Irkutsk Oblast has got an area larger than the area of say Germany, 
California, or France. The nature, woods, rivers, lakes, etc. there is 
amazing. It is one of the most beautiful regions of the planet.


Actually the whole territory at and around this node is coniferous 
forest which is not mapped yet, and that is why also not visible on 
the macro-map.


This is exactly what bothers me with macro scale - there are really big 
areas on the planet which are not mapped yet and we have just plain land 
color there as if there was nothing. Irkutsk is just one of them.


Continent tagging as a node is just a workaround, because we don't know 
how to do it better. But with forest it should be easy already (we know 
how to do it properly, just nobody did it yet). I'm also yet to see big 
Eurasian Steppe belt (https://en.wikipedia.org/wiki/Eurasian_Steppe) or 
any other steppe around the world 
(https://commons.wikimedia.org/wiki/File:Steppe_world.png) and we have 
"grassland" tag for this probably.


If something like this can be done with current tools, but it's not, 
means to me that we don't care for macro scale at the moment. That's why 
I try to bring the subject to the table.


--
"Like a halo in reverse" [M. Gore]


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

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

[Lester Caine]

On 22/08/17 17:19, Philip Barnes wrote:
>> called differently, but this is it:
>> https://wiki.openstreetmap.org/wiki/Key:maxspeed:practical
>>
> Isn"t that going to be rather subjective?

And will depend on 'time of day' ;)

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

Re: [Talk-GB] Are Northern Ireland, Wales & England 'states'?

[Lester Caine]

On 22/08/17 12:23, Colin Smale wrote:
> If you ask people where they live, they will probably talk about the
> county level and the settlement/town/city, but the informal boundaries
> of these settlements will likely not follow the administrative
> boundaries. In fact, it may not be possible to agree a polygon with a
> sharp boundary of what constitutes a settlement with a given name. Most
> place=* polygons in OSM just follow the boundary of the built-up area.
> 
> So I see a possible role for is_in - to help out geocoding where
> geometrical methods lead to an undesirable (though accurate) result.

Middlesex ceased to exist in 1965 yet many people still use it in their
postal address ... there is certainly no boundary for it on OSM :) To
add to the fun, facebook's allowed list of places miss-identifies this
area of London in the same way as the other areas that became London
Boroughs back then and this is creating a mess in Facebook's use as a
business platform.

Starting with a list of the current official designations from the ONS
database has to be the correct currently accurate information, but while
there should be a boundary associated with each entry, a simple list of
elements does not need to be overloaded with all of the way information
providing that boundary. It is a secondary relation to the base 'name'.

http://geoportal.statistics.gov.uk/datasets/0e7bbf9926584a57a2818c64f01d0bfe_0/data
provides a list of the official COUNTRIES in the United Kingdom but even
that is probably inaccurate in relation to is Northern Ireland part of
the United Kingdom? ( At some time will Scottish translations also be
added? )

The Open Geography Portal provides a list of data and the basis for
checking that within OSM, but it will be easier to complete a complete
mirror of is_in: hierarchy which can be updated as changes appear in the
ONS dataset and THEN associate boundaries as appropriate.

-- 
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-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

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

[Philip Barnes]

On 22 August 2017 14:46:33 BST, Richard  wrote:
>On Tue, Aug 22, 2017 at 08:40:13AM -0400, Greg Troxel wrote:
>> 
>> Two points:
>> 
>>   Speed limit does not describe the speeds that reasonably
>responsible
>>   real people actually drive on roads.  The UK/IE notion of 60 mph on
>>   all roads out of village centers is one example.  Another is in the
>US
>>   where there are many roads signed 65 mph where traffic normally
>moves
>>   at 80 mph.  So, what I think OSM needs a few things:
>> 
>> - A) a "typical_speed" tag, to be used by routers instead of
>>   speed_limit
>
>called differently, but this is it:
>https://wiki.openstreetmap.org/wiki/Key:maxspeed:practical
>
Isn"t that going to be rather subjective?

Phil (trigpoint) 



-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

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

[Lester Caine]

On 22/08/17 12:29, Colin Smale wrote:
> I would like to take a closer look at your example route... Can you give
> start and end locations?

http://map.project-osrm.org/?z=11=52.149501%2C-1.577225=52.048797%2C-1.856918=52.258912%2C-1.619625=en=0

43.4km 33min

Dragged to normal route via Mickleton it becomes 32.3km 34min, but
anybody who uses this section of the A46 will tell you that it's often
stationary traffic even on the dual bits ... so the quoted times are
simply wrong a lot of the time.

To add to the fun Warwickshire has decided they will enforce a county
wide 50MPH maximum overriding the national limit so some of the long
straight sections we 'should' be slowing down while some sections of the
A46 are 70, but the same 50 limit applies to other long stretches on the
A46 as well ;)

I have a smaller problem heading south to the M5 and again 'shortest'
picks the quick route but then avoids the M5 as well :) Interesting ...
checking OSRM is getting it right so I need to check OSMAND again on that.

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

Re: [OSM-talk-fr] OSM à la plage;-) . Était : le festival de tout les highway :-)

[Philippe Verdy]

Le 22 août 2017 à 16:33, Christian Rogel 
a écrit :

>
> Le 2017 Eost 21 à 23:51, Philippe Verdy  a écrit :
>
>
>  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
>
>
>
> Vrai, on a un texte (lexique de médecin herboriste) qui daté du milieu du
> 9ème. Il est « armoricain » pour les fioritures de son écriture, mais, on
> écrivait la même langue des deux côtés de la Manche jusqu’au 11ème.
>
> 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)
>
>
> Sûrement pas le mannois (Île de Man) qui est une langue Q-celtique
> apparenté à l’irlandais et au gaéique écossais.
>

Justement si avec le mannois (à l'oral dans leurs forme vernaculaire).
C'est connu par les témoignages écrits (en français ou anglais) rapportés
de pêcheurs et des commerçants dans les ports, et des écrits paroissiaux,
notariés, des actes de justice, des voyageurs, et dans les armées, les
anciens pêcheurs du Guilvinec dans les années 1970 témoignaient encore
eux-mêmes de leur expérience ou celle de leurs parents, quand ils prenaient
abris dans les ports des uns et des autres en cas de gros temps, fréquent
en mer d'Irlande et mer d'Iroise, ou se portaient secours entre eux :
c'était alors très facile d'échanger en breton et mannois plutôt qu'en
français ou anglais dont ils ne comprenaient que des bribes.

Alors qu'il n'y avait plus d'intercompéhension avec l'irlandais ou le
gaélique écossais qui avaient beaucoup évolué (avec de nombreux emprunts à
l'anglais et une modification sensible des accents et une phonétique
altérée par les diphtongues, la rythmique et la tonalité).

Pour les formes écrites, je n'en sais rien, les pêcheurs pour la plupart ne
savaient pas lire aussi bien en Bretagne que dans les îles, l'orthographe
n'ayant pas été normalisée encore dans leurs langues contrairement au
français et l'anglais dominant.

Même encore aujourd'hui l'orthographe bretonne a plusieurs écoles, avec le
vannetais qui se distingue des 3 autres principales formes dialectales, et
donc deux orthographes encore en compétition (il y en a eu plus dans le
passé), et il reste des désaccords sur l'emploi ou non des diacritiques
pour tenter d'unifier et reconnaître les formes dialectales (les vannetais
ne sont pas satisfaits du fait que la norme oublie de différencier des
phonologies qu'ils considèrent comme clairement distinctes et des auteurs
vannetais dévient volontairement de la norme développée par l'office de la
langue bretonne ou inisste pour qu'on y ajoute des termes vannetais qui
leurs sont propres pour enrichir le vocabulaire commun au lieu de le
réduire à une forme dominante).

Les toponymes ont, eux, eu une conservation plus longue et là les
différentes langues celtiques se distinguent facilement, mais on n'a pas
d'intercompréhension à considérer à ce niveau puisqu'ils sont compris (à
l'oral) tels quels indépendamment des langues avec des différences
assimilées à des différences d'accent.


> Ceci m’amène à traiter la question du tagging des rivages complexes,
> rocheux ou sableux.  On a édité une série de 12 livres en breton sur les
> noms des côtes du Nord-Finistère. Pour deux communes, Ploudalmézeau et
> Lampaul-Ploudalmézeau, ce n’est pas moins de 700 toponymes qui ont été
> recueillis auprès des pêcheurs et des goémoniers.
> Tout avait un nom, rocher en mer et sur les dunes, passages entre rochers
> à marée, une île pouvait avoir chacun de ses faces nommées (Fri Karn et
> Skoaz Karn faisant allusion au « nez et à « l’épaule ») pour l’Ïle Carn.
>
> Un constat : les caps et les rochers isolés ne sont pas dans le rendu OSM
> standard.
>
>
> 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] Création de la liste OSM tagging-fr - communication - fragmentation

[Jean-Marc Liotier]

On Tue, 22 Aug 2017 14:21:00 +
marc marc  wrote:
>
> pour rebondir sur ton exemple, 16 ml locales, quasi + que d'actif.
> un paquet n'a pas eu de message cette année, une partie est à 1/mois
> n'est-on pas allez trop loin ? 5 ne serraient-ils pas suffisant ?

Une partie de ces listes sont en pratique plutôt des canaux de diffusion
d'annonces et non des lieux de discussion - la spécificité nationale
est donc peut-être importante, malgré l'apparence d'insignifiance.
J'ignore si les abonnés en sont satisfaits.

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

Re: [OSM-talk-fr] tag network sur les lignes de bus

[marc marc]

Le 22. 08. 17 à 16:32, lenny.libre a écrit :
> Le 20/08/2017 à 12:02, marc marc a écrit :
>> Le 20. 08. 17 à 11:20, lenny.libre a écrit :
>>> 4- Bien que le wiki l'indique sur chaque objet,
>> quelle page ?
> indiqué sur chaque objet, mais avec des degrés d'importance :
> https://wiki.openstreetmap.org/wiki/Public_transport "recommended"
Sur cette page, c'est bien les relations route et route_master sur 
lesquelles c'est recommandé de mettre le tag.
Cette même page wiki ne parle pas d'ajouter cela au mobilier urbain.

J'ai été rechercher la proposition d'origine soumise au vote.
Elle conseille de mettre le tag sur le stop_area au lieu du mobilier urbain.
Elle ne recommande de le mettre sur le node que si c'est la seule chose 
qui existe (donc en l'absence de stop_position et stop_area).
Même règle pour le tag operator dans la proposition votée.

J'espère que cela permettrait d'éviter les yop-yop actuels (dupliquer 
sur le mobilier urbain <> d'autres les retirent)
Qu'en pensez-vous ? particulièrement Jo ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Retour sur le State of the Map 2017 (Japon)

[PanierAvide]

Bonjour,

Les slides des présentations doivent être mises à disposition par 
l'équipe du SoTM si je me souviens bien. Je n'ai pas réussi à les 
trouver par ailleurs, peut-être contacter Frederik Ramm directement ?


Cordialement,

Adrien.


Le 22/08/2017 à 16:51, François Lacombe a écrit :

Bonjour Adrien et merci pour ce compte rendu.

Je serai très intéressé par le comparatif sur les outils de routage.
Est-ce qu'il y a de la documentation quelque part ou les slides sont 
visibles en ligne ?


Je ne connaissais pas bute de geofabrik par exemple

A+

François

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com 
@InfosReseaux 

Le 22 août 2017 à 16:02, PanierAvide > a écrit :


Bonjour à tous,

Cette année, trois contributeurs français se sont rendus à la
rencontre annuelle mondiale d'OpenStreetMap : le State of the Map,
qui se déroulait au Japon.

Un retour d'expérience (écrit collaborativement) est disponible
sur : http://openstreetmap.fr/sotm-japon-2017


Cordialement,

Adrien.


___
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] Retour sur le State of the Map 2017 (Japon)

[François Lacombe]

Bonjour Adrien et merci pour ce compte rendu.

Je serai très intéressé par le comparatif sur les outils de routage.
Est-ce qu'il y a de la documentation quelque part ou les slides sont
visibles en ligne ?

Je ne connaissais pas bute de geofabrik par exemple

A+

François

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

Le 22 août 2017 à 16:02, PanierAvide  a écrit :

> Bonjour à tous,
>
> Cette année, trois contributeurs français se sont rendus à la rencontre
> annuelle mondiale d'OpenStreetMap : le State of the Map, qui se déroulait
> au Japon.
>
> Un retour d'expérience (écrit collaborativement) est disponible sur :
> http://openstreetmap.fr/sotm-japon-2017
>
> Cordialement,
>
> Adrien.
>
>
> ___
> 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 à la plage;-) . Était : le festival de tout les highway :-)

[Christian Rogel]

> Le 2017 Eost 21 à 23:51, Philippe Verdy  a écrit :
> 

>  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


Vrai, on a un texte (lexique de médecin herboriste) qui daté du milieu du 9ème. 
Il est « armoricain » pour les fioritures de son écriture, mais, on écrivait la 
même langue des deux côtés de la Manche jusqu’au 11ème.

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

Sûrement pas le mannois (Île de Man) qui est une langue Q-celtique apparenté à 
l’irlandais et au gaéique écossais. Pas avec le gallois, non plus, depuis le 
Haut Moyen-Âge. L’intercompréhension a du être possible avec le cornique 
jusqu’à la Rennaissance, au cours de laquelle il s’éteint.
Me promenant en Cornouaille, je comprenais certains noms de lieu et les numéros 
donnés en lettres.

Ex : D. du Maurier a écrit « The House on the Strand », ce qui est la 
traduction du nom d’un village, Tywardreath   
lequel existe encore au bord d’un ancien estuaire maintenant comblé. Un 
brittophone n’a pas besoin de traduction, car il écrirait  « Ti war draezh » 
(ou Tiwardraezh) et prononcerait « Ti war drêz » .

Ceci m’amène à traiter la question du tagging des rivages complexes, rocheux ou 
sableux.  On a édité une série de 12 livres en breton sur les noms des côtes du 
Nord-Finistère. Pour deux communes, Ploudalmézeau et Lampaul-Ploudalmézeau, ce 
n’est pas moins de 700 toponymes qui ont été recueillis auprés des pêcheurs et 
ds goémoniers.
Tout avait un nom, rocher en mer et sur les dunes, passages entre rochers à 
marée, une île pouvait avoir chacun de ses faces nommées (Fri Karn et Skoaz 
Karn faisant allusion au « nez et à « l’épaule ») pour l’Ïle Carn.

Un constat : les caps et les rochers isolés ne sont pas dans le rendu OSM 
standard.


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

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[lenny.libre]

Le 20/08/2017 à 12:02, marc marc a écrit :

Le 20. 08. 17 à 11:20, lenny.libre a écrit :

4- Bien que le wiki l'indique sur chaque objet,

quelle page ?

indiqué sur chaque objet, mais avec des degrés d'importance :
https://wiki.openstreetmap.org/wiki/Public_transport "recommended"
https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route_direction.2Fvariant 
"recommended if no route_master 
=* exists, else 
optional "
https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route_master 
" recommended if available "
https://wiki.openstreetmap.org/wiki/Tag%3Apublic_transport%3Dstop_position 
"recommended if no public_transport 
=stop_area 
 
exists, otherwise optional"
https://wiki.openstreetmap.org/wiki/Tag%3Apublic_transport%3Dplatform 
"recommended if no public_transport 
=stop_area 
 
exists, else optional "
https://wiki.openstreetmap.org/wiki/Tag%3Apublic_transport%3Dstation 
"Optional"
https://wiki.openstreetmap.org/wiki/Tag%3Apublic_transport%3Dstop_area 
"Important, if available "

https://wiki.openstreetmap.org/wiki/Public_transport/Quality_Assurance#Public_transport_objects_without_network.3D.2A

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

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr - communication - fragmentation

[marc marc]

Le 22. 08. 17 à 03:13, Vincent de Château-Thierry a écrit :
> Le 21/08/2017 à 12:51, marc marc a écrit :
>> De toute façon à mes yeux, le cas est limpide et caricatural.
>> Un inconnu arrive sans discussion pour présenter son "bébé" et ne dit
>> pas un mot aux réaction, c'est un projet purement personnel de son
>> auteur, y a qu'à cliquer. Pour caricaturer, c'est un spam :-)
> Attention aux caricatures... Que tu ne connaisses pas Séverin est une 
> chose. Le qualifier d'inconnu par ici, en revanche... non.
oui j'avais bien dit "caricatural"
1 message ici cette année, 1 message ici l'an passé.
bien sur ailleurs du monde le connaît, mais ICI, pour utiliser un terme 
plus juste, on ne peux vraiment parler d'un actif ni de communauté.
j'ai été voir un peu dans l'historique des 3 dernières années, il est 
actif dans hot, au point qu'il a décidé qu'il avait besoin de 
hot-francophone, déjà à l'époque la communauté concerné lui avait fait 
le reproche de se la faire perso sans concertation. sa réponse est assez 
limpide "you do not know well how the OSM lists work. Any group can 
<...> create one". est-cela qu'on souhaite comme fonctionnement ?
Cette nouvelle ml a entre 1 message par mois et 1 message par jour sur 
les 6 derniers mois. c'est comme pour le tagging-fr à mon avis largement 
supportable dans la ml d'origine avant la division.
d'ailleurs j'aurais pu participer à une partie des sujets si cela ne 
s'était pas passé sur "encore une ml supplémentaire où s'inscrire".
Niveau tag, sur 3 ans, j'ai pas trouvé de proposition de sa part,
pas trouvé de participation aux proposition de la collectivité,
juste quelques questions auquel il ne réagit généralement pas.
Bref, où est le besoin de fractionner talk-fr pour si peu ?

> Au fil des années ont émergé un paquet de canaux, pour ne parler que des 
> franco-français. On a des ML locales
pour rebondir sur ton exemple, 16 ml locales, quasi + que d'actif.
un paquet n'a pas eu de message cette année, une partie est à 1/mois
n'est-on pas allez trop loin ? 5 ne serraient-ils pas suffisant ?
genre idf-nord-ouest-est-sud ?
surtout qu'en survolant ces ml, la moitié des questions n'ont rien de local.
est-ce dérangeant si on a qlq annonce/mois d'une action locale sur 
talk-fr ? moi je trouverais cela positif, cela dynamiserait.

l'humain aime créer du nouveau c'est associé à l'idée d'utile.
l'humain n'aime pas fermer, c'est associé à l'idée d'échec.
pourtant parfois, le plus utile c'est de ne pas créer ou de fusionner

>> Ce qui me semblerait utile c'est d'abolir les barrières techniques entre
>> ces différentes canaux.
>> Par exemple la ml talk-fr a déjà une interface web.
>> il ne manque pas grand chose pour rendre la ml utilisable comme un forum
>> (on sait déjà s'identifier et lire, il manque juste la possibilité de
>> faire une réponse via page web au lieu de l'ouverture d'un client mail)
> Sauf erreur c'est déjà possible via Nabble :
> http://gis.19327.n8.nabble.com/France-f5380434.html

je vais faire un autre sujet avec ce point
Le 22. 08. 17 à 12:25, Christian Rogel a écrit :
 > On devrait y retrouver bientôt l'annonce de Tagging-fr.
quand je constate que la majorité exprimé trouve l'idée problématique, 
c'est dommage de promouvoir une fragmentation de la communauté.

Le 22. 08. 17 à 14:08, PanierAvide a écrit :
 > On a lancé le concept de l'agent conversationnel OSM communauté

Qui est "on" ? osm-fr ? la rédaction HebdoOSM-fr ?
Sacré terme mais très bonne idée !
Si souhaité, je pourrais faire un mot sur les harmonisations de tag.
Ton travail d'inventaire sur l'accessibilité et sa page wiki mériterait 
aussi un peu de visibilité (j'étais tombé dessus par hasard).

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

[Talk-cz] WeeklyOSM CZ 369

[Tom Ka]

Ahoj, je dostupné vydání 369 týdeníku WeeklyOSM:

http://www.weeklyosm.eu/cz/archives/9374

* Další kvartální pivo se blíží.
* Body záchrany jako otevřená data?
* Opilý lyžař na freemap.sk.
* Sociální inženýrství a OSM.
* Vícejazyčné oblasti v OSM.
* Proběhlo SotM 2017.
* Záplavy v Nepálu.
* Rychlejší GraphHopper.
* Drony proti minám.

Pěkné počtení ...

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

[OSM-talk-fr] Retour sur le State of the Map 2017 (Japon)

[PanierAvide]

Bonjour à tous,

Cette année, trois contributeurs français se sont rendus à la rencontre 
annuelle mondiale d'OpenStreetMap : le State of the Map, qui se 
déroulait au Japon.


Un retour d'expérience (écrit collaborativement) est disponible sur : 
http://openstreetmap.fr/sotm-japon-2017


Cordialement,

Adrien.


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

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

[Richard]

On Tue, Aug 22, 2017 at 08:40:13AM -0400, Greg Troxel wrote:
> 
> Two points:
> 
>   Speed limit does not describe the speeds that reasonably responsible
>   real people actually drive on roads.  The UK/IE notion of 60 mph on
>   all roads out of village centers is one example.  Another is in the US
>   where there are many roads signed 65 mph where traffic normally moves
>   at 80 mph.  So, what I think OSM needs a few things:
> 
> - A) a "typical_speed" tag, to be used by routers instead of
>   speed_limit

called differently, but this is it:
https://wiki.openstreetmap.org/wiki/Key:maxspeed:practical

Richard

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

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr

[lenny.libre]

Le 20/08/2017 à 00:12, marc marc a écrit :

Bonsoir,

Le 19. 08. 17 à 22:16, Severin Menard a écrit :

annoncer la création de la liste de discussion OSM tagging-fr

C'est en soi une très bonne idée que de fédérer la francophonie.

Mais quand je vois que pour la discussion de certains tag, on n'est
parfois pas nombreux à en discuter sur talk-fr, je me demande si diviser
avec une ml supplémentaire n'est pas contre productif,
Je me souviens même pas de t'y avoir lu ce mois-ci ni d'y lu l'idée.
Cordialement,
Marc

+1

lorsque j'ai commencé le fil "bus : lignes de transport en commun 
Haute-Garonne : réseau" que j'aurais dû appeler "network / bus : lignes 
de transport en commun Haute-Garonne" je me suis demandé si je le 
faisais sur la liste transport ou la liste talk , puis je me suis dit 
que network avait un impact au-delà de la seule vue transport, je l'ai 
donc mis sur talk (et on y a parlé des tags "**:wikidata")


et comme on parle de tag sur les 2 listes + le forum , rajouter une 3ème 
liste ...


leni

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

Re: [Talk-GB] Are Northern Ireland, Wales & England 'states'?

[Colin Smale]

Of course. But accuracy (perhaps correctness is a better word here) is
relative to some frame of reference. What is right under some
circumstances can be wrong under other circumstances. If you are a
postman, you have a different view of toponymy than a local government
official, a visitor or a resident. There are many versions of "correct".
This is exactly the core of the problem: people are looking for a single
solution for a polyvalent problem. If the solutions align, it is by
coincidence, not design. We should stop tilting at windmills and adjust
our world-model.

If there is a defined boundary, it can be captured as polygon. Often it
is not that simple. 

On 2017-08-22 15:21, Dave F wrote:

> Accurate *as possible*
> 
> On 22/08/2017 13:59, Colin Smale wrote: 
> 
> That depends on your definition of "accurate", doesn't it?
> 
> On 2017-08-22 14:15, Dave F wrote: 
> But a query to the OSM database isn't interested in what 'locals' 
> misinterpret, it's interested in what OSM returns.
> 
> The ignorance of the person on the street is just one reason why OSM needs to 
> exist & be as accurate as possible.
> 
> DaveF
> 
> On 22/08/2017 12:50, Andy Townsend wrote: On 22/08/2017 12:23, Colin Smale 
> wrote: 
> What would a "local" answer? 
> Good luck getting a consistent answer to that :)
> 
> http://ma3t.co.uk/euanmills/euanmills/tifd.html
> 
> Best Regards,
> 
> Andy
> 
> (and apologies in advance for anyone upset by small-font profanity in the 
> link)
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

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

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[Christian Quest]

Les ref stables et id wikidata permettent à des scripts d'accéder sans 
équivoque aux infos.


Les name (pourquoi pas network:name) sont destinés à des humains... les 
deux se complètent et pour l'instant network=* fait (mal) un peu les deux.


Dans beaucoup de scripts, j'utilise les ref:INSEE pour identifier une 
commune là où un humain utilisera plutôt le nom (name) de la commune, et 
c'est bien normal.




Le 22/08/2017 à 14:35, marc marc a écrit :

Le 21. 08. 17 à 23:20, osm.sanspourr...@spamgourmet.com a écrit :
  >> MM> puisqu'il est mieux de faire sans relation network,
  >> MM> le débat est rouvert sur comment les séparer facilement.
J>>> network:wikidata  ...
MM>> cela implique de dépendre de wikipedia pour afficher/trouver le nom
MM>> d'une réseau de bus...
  > Non, tu intègres l'objet wikidata dans OSM ,il a donc son existence
  > propres, tu t'y réfères pour mettre à jour les noms.
oui, quand tu connais le code wikidata, tu peux facilement retrouver
tout les objets. c'est donc pratique pour la maintenance une fois un
travail préalable d'harmonisation de l'existant.
c'est dans cette phase qu'il y a cette "dépendance"

Le 21. 08. 17 à 20:28, lenny.libre a écrit :

Le principal avantage que je vois dans la relation c'est ce qu'il m'a
semblé comprendre de ce disait Philippe : le tag "network", c'est
uniquement un code

Je pense avoir lu Noémie qui disait que cela servait à afficher le nom
(au sens commercial) du réseau à l'utilisateur et qu'en ce sens, il
devrait correspondre au nom connu de l'utilisateur.


on peut aussi y mettre wikidata pour avoir l'unicité)
le jour ou le nom du réseau change, il suffirait de changer le name

avec ou sans relation network, je pense que c'est ainsi qu'il serrait le
plus utile : utiliser network:wikidata comme une référence (on aurait pu
mettre ref=123) permettant de sélectionner toutes les master_route d'un
réseau.
Un query overpass dans josm suffit à sélectionner toute le réseau pour
uniformiser ou changer le nom
qu'en pensez-vous de ce compromis ?

il resterait alors à se mettre d'accord sur quoi faire lorsqu'un petit
réseau de bus n'a pas la notoriété suffisante que pour être dans
wikipedia. wikidata a les même règles de notoriété que wikipedia ?
ou sinon simplement on fait une page wiki qui liste des
ref:FR:network:bus et on attribue 1 au premier cas qui se présente, puis
2, 3 etc la page wiki servant de remplacement "wikidata"
on peux bien évidement mettre une ref plus simple genre ref:FR:osmdata
qui pourrait servir à tout les objets n'ayant de référence wikidata mais
qui aurait utilement besoin d'une ref unique.
___
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

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

[marc marc]

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
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Select and correct a discovered key duplication of sorts in JOSM

[David Groom]

Alternatively in JOSM:

File > Download from Overpass API

Then put  ref:Chiltern_Society = *  in the text box next to "Build 
query", then click "Build Query".

Next select download area, and then click "Download"

David

-- Original Message --
From: "Bob Hawkins" 
To: talk-gb@openstreetmap.org
Sent: 19/08/2017 16:55:03
Subject: Re: [Talk-GB] Select and correct a discovered key duplication 
of sorts in JOSM


My failing brain disturbs me at times: Edit>Preferences>Remote 
Control>Enable remote control!


Virus-free. 
www.avast.com 
 
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Are Northern Ireland, Wales & England 'states'?

[Dave F]

Accurate *as possible*

On 22/08/2017 13:59, Colin Smale wrote:


That depends on your definition of "accurate", doesn't it?


On 2017-08-22 14:15, Dave F wrote:

But a query to the OSM database isn't interested in what 'locals' 
misinterpret, it's interested in what OSM returns.


The ignorance of the person on the street is just one reason why OSM 
needs to exist & be as accurate as possible.


DaveF

On 22/08/2017 12:50, Andy Townsend wrote:

On 22/08/2017 12:23, Colin Smale wrote:


 What would a "local" answer?


Good luck getting a consistent answer to that :)

http://ma3t.co.uk/euanmills/euanmills/tifd.html

Best Regards,

Andy

(and apologies in advance for anyone upset by small-font profanity 
in the link)


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



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



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


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

Re: [Talk-GB] Are Northern Ireland, Wales & England 'states'?

[Colin Smale]

That depends on your definition of "accurate", doesn't it?

On 2017-08-22 14:15, Dave F wrote:

> But a query to the OSM database isn't interested in what 'locals' 
> misinterpret, it's interested in what OSM returns.
> 
> The ignorance of the person on the street is just one reason why OSM needs to 
> exist & be as accurate as possible.
> 
> DaveF
> 
> On 22/08/2017 12:50, Andy Townsend wrote: On 22/08/2017 12:23, Colin Smale 
> wrote: 
> What would a "local" answer?
> 
> Good luck getting a consistent answer to that :)
> 
> http://ma3t.co.uk/euanmills/euanmills/tifd.html
> 
> Best Regards,
> 
> Andy
> 
> (and apologies in advance for anyone upset by small-font profanity in the 
> link)
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

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

[Greg Troxel]

Lester Caine  writes:

>> 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 !). 
>
> Single carriageway roads here are 60MPH out of town and 30MPH in town
> but I'm not sure OSMAND actually understands that anyway applying 20MPH
> limit to all secondary and tertiary roads? The routes I am talking about
> are tertiary roads with 40 and 50MPH speed limit sections ... I do add
> them in where I find them, but many were not showing in North Wales :(

I agree with Lester, basically.  In the US, a problem with OSMand is
applying the motorway speed limit to a motorway_link.  Technically
that's sort of true legally, but it leads to routes that get off and
back on again, which is not only crazy but wrong, because driving that
way takes longer.  People have asked to have foo_link be half the speed
of foo, and I don't know if that's happened.

Two points:

  Speed limit does not describe the speeds that reasonably responsible
  real people actually drive on roads.  The UK/IE notion of 60 mph on
  all roads out of village centers is one example.  Another is in the US
  where there are many roads signed 65 mph where traffic normally moves
  at 80 mph.  So, what I think OSM needs a few things:

- A) a "typical_speed" tag, to be used by routers instead of
  speed_limit

- B) a project-curated worldwide  machine-readable ruleset that maps
  tags (including classifications, lanes, speed limit, and anything
  else) and possibley some geometry rules (distance between
  intersections) to the value "typical speed" should have, in cases
  where it isn't explicitly there.

- C) perhaps a database of typical speeds, outside the map, that can be
  crowdsourced in some privacy-respecting way, that routers can use
  instead of A and B.

   Routing programs are often not quite right.  Routing is hard.  But I
   cannot agree with the notion that the way to fix routing is to change
   how we use highway tags and especially trunk.  Routers should be
   attempting to answer "if I took this route, how long would it take in
   both distance and time" as a prelude to finding a route with a
   minimal combined metric, and that's about many things and not really
   about classification. If a router really wants you to take a road
   solely because of classification, that seems like a bug.


signature.asc
Description: PGP signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[marc marc]

Le 21. 08. 17 à 23:20, osm.sanspourr...@spamgourmet.com a écrit :
 >> MM> puisqu'il est mieux de faire sans relation network,
 >> MM> le débat est rouvert sur comment les séparer facilement.
J>>> network:wikidata  ...
MM>> cela implique de dépendre de wikipedia pour afficher/trouver le nom
MM>> d'une réseau de bus...
 > Non, tu intègres l'objet wikidata dans OSM ,il a donc son existence
 > propres, tu t'y réfères pour mettre à jour les noms.
oui, quand tu connais le code wikidata, tu peux facilement retrouver 
tout les objets. c'est donc pratique pour la maintenance une fois un 
travail préalable d'harmonisation de l'existant.
c'est dans cette phase qu'il y a cette "dépendance"

Le 21. 08. 17 à 20:28, lenny.libre a écrit :
> Le principal avantage que je vois dans la relation c'est ce qu'il m'a 
> semblé comprendre de ce disait Philippe : le tag "network", c'est 
> uniquement un code
Je pense avoir lu Noémie qui disait que cela servait à afficher le nom 
(au sens commercial) du réseau à l'utilisateur et qu'en ce sens, il 
devrait correspondre au nom connu de l'utilisateur.

> on peut aussi y mettre wikidata pour avoir l'unicité)  
> le jour ou le nom du réseau change, il suffirait de changer le name
avec ou sans relation network, je pense que c'est ainsi qu'il serrait le 
plus utile : utiliser network:wikidata comme une référence (on aurait pu 
mettre ref=123) permettant de sélectionner toutes les master_route d'un 
réseau.
Un query overpass dans josm suffit à sélectionner toute le réseau pour 
uniformiser ou changer le nom
qu'en pensez-vous de ce compromis ?

il resterait alors à se mettre d'accord sur quoi faire lorsqu'un petit 
réseau de bus n'a pas la notoriété suffisante que pour être dans 
wikipedia. wikidata a les même règles de notoriété que wikipedia ?
ou sinon simplement on fait une page wiki qui liste des 
ref:FR:network:bus et on attribue 1 au premier cas qui se présente, puis 
2, 3 etc la page wiki servant de remplacement "wikidata"
on peux bien évidement mettre une ref plus simple genre ref:FR:osmdata 
qui pourrait servir à tout les objets n'ayant de référence wikidata mais 
qui aurait utilement besoin d'une ref unique.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Are Northern Ireland, Wales & England 'states'?

[Dave F]

But a query to the OSM database isn't interested in what 'locals' 
misinterpret, it's interested in what OSM returns.


The ignorance of the person on the street is just one reason why OSM 
needs to exist & be as accurate as possible.


DaveF

On 22/08/2017 12:50, Andy Townsend wrote:

On 22/08/2017 12:23, Colin Smale wrote:


 What would a "local" answer?



Good luck getting a consistent answer to that :)

http://ma3t.co.uk/euanmills/euanmills/tifd.html

Best Regards,

Andy

(and apologies in advance for anyone upset by small-font profanity in 
the link)


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



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

Re: [Talk-GB] Are Northern Ireland, Wales & England 'states'?

[Dave F]

OSM is geospatially aware. I'm unsure why there's a reluctance to use it.

is_in tags are far more "incomplete and imperfect" than boundaries.
Boundaries are maintained far more than the antiquated is_in:*.

*Every* entity will require a full set of is_in tags to be workable.

If an entity is in "no-mans-land" of boundaries, it will be in 
"no-mans-land" if tag with is_in, Using geospatial calculation with 
boundaries it will know it's 'outside' but be able to find the nearest 
area. Describing it a 'near to...' isn't perfect but better than nothing 
which is what you'd get using is_In.


DaveF


On 22/08/2017 12:23, Colin Smale wrote:


Let's have some use cases out on the table... if my location is 
{lat,lon}, where am I? What answer am I expecting? Postal address? 
Town or other settlement? The local council? What would a "local" answer?


In the UK, the hierarchy of admin boundaries is incomplete and 
imperfect - there are unparished areas, and combined authorities for 
example. There are so many black holes in the UK - where you are in 
no-mans-land "between A and B but in neither." If nobody lives there, 
is it actually necessary to be able to say where you are?


If you ask people where they live, they will probably talk about the 
county level and the settlement/town/city, but the informal boundaries 
of these settlements will likely not follow the administrative 
boundaries. In fact, it may not be possible to agree a polygon with a 
sharp boundary of what constitutes a settlement with a given name. 
Most place=* polygons in OSM just follow the boundary of the built-up 
area.


So I see a possible role for is_in - to help out geocoding where 
geometrical methods lead to an undesirable (though accurate) result.


//colin

On 2017-08-22 12:57, Dave F wrote:



This is a reply to a Q. I posed on Talk. Nominatum clearly prefer 
boundaries to is_in & say it's not heavy processing:

https://lists.openstreetmap.org/pipermail/talk/2016-August/076596.html

As UK boundaries are sure be updated in OSM, keeping the secondary 
is_in 'cleanly managed' will be a major task.


On 22/08/2017 09:38, Lester Caine wrote:

On 12/08/17 13:12, Dave F wrote:

I also think the 'is_in:country_code' along with all 'is-_in' tags are
redundant if there's a boundary tag..

In the past I thought that the is_in element was something of a problem,
but it does have a place when one remembers that OSM is all about the
data. "if there's a boundary tag" is the problem here if one is
extracting a set of data? Processing a number of boundaries around a set
of objects takes time, while cleanly managed is_in:admin_area with a
proper hierarchy allows a much quicker lookup of information such as -
in the case of the the UK - parliamentary boundaries, wards, historic
county, NHS admin area and so on without having to physically draw every
fine detail of these ever changing boundaries. BUT it only works well if
there is a well defined hierarchy so tagging is_in:gb-ward
http://geoportal.statistics.gov.uk/datasets/417e93f21c5c419283ac23abc8eedcce_0
gives all this data in a format we can freely use as with the other
'boundary' data.

It is just a pity that 'postcode' is so badly organised that it quite
regularly straddles these other boundaries, but is_in:gb-postcode would
remove the need to add all of the associated address data to every
object on a particular street, and for the vast majority of postcodes it
WOULD also identify all of the other is_in: data at a higher level. It
just needs an object defining is:gb-postcode and is:gb-ward to provide
all the hierarchy ... without overloading the server with searches for
all of the boundaries intersecting the original dataset?

Of cause I am also still looking to maintain access to historic data,
and this model makes it easy to check start and end dates of
is:gb-postcode and is:gb-ward without having to maintain all of those
boundaries actually in the base dataset - something which the majority
of users seems to have decided against :(



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



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


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

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr

[PanierAvide]

C'est un sujet que l'on a évoqué de manière informelle avec Florian, le 
fait d'avoir une communication plus régulière et plus visible sur ce qui 
se passe au niveau national et local. L'équilibre est à trouver entre le 
temps nécessaire pour rédiger des articles/nouvelles (tâche plutôt 
chronophage) et la nécessité de rendre visible nos projets et actions 
(sans quoi la communauté n'apparaît pas exister). On a lancé le concept 
de l'agent conversationnel OSM communauté :


- L'agent obtient des infos en contactant des membres, par exemple ceux 
ayant réalisés beaucoup de contributions sur une même zone, ou les 
développeurs de projets pour lesquels on n'a pas eu d'infos depuis 
quelques temps. Le robot demande ainsi à la personne d'expliquer sa 
démarche et ses actions en cours. Le tout en ayant au final peu de temps 
à y consacrer (une brève pouvant être écrite en quelques minutes).


- L'agent peut également envoyer à sa liste d'abonnés des condensés 
d'informations réguliers, générés à partir des infos remontées 
précédemment. Cela permet aux abonnés de se tenir au courant sans avoir 
à aller chercher l'info. Le format court des infos remontées assure 
également une régularité de la diffusion.


- Enfin, ces mêmes infos peuvent apparaître sous la forme d'un flux de 
nouvelles sur une page web, accessible depuis le site osm.fr, donnant 
une visibilité aux actions de la communauté.


Au-delà de cet exemple de solution, il y a un vrai enjeu sur la 
communication, à la fois pour consolider la communauté et pour augmenter 
sa visibilité, et donc potentiellement attirer de nouveaux participants. 
À méditer donc ;-)


Adrien.


Le 22/08/2017 à 12:25, Christian Rogel a écrit :

Salut, Adrien,
On attend le CR et, donc, un petit résumé ici sera bienvenu, comme je 
le disais.

Ma remarque concernait l'avant SotM 2017.
Ceux qui ne sont pas dans la partie organisée de la communauté 
n'avaient aucun moyen de savoir qu'il allait avoir lieu, à moins de 
s'abonner à HebdoOSM 
http://www.weeklyosm.eu/fr/archives/9374 S'abonner via col. de droite 
"Suscribe to OSM".

On devrait y retrouver bientôt l'annonce de Tagging-fr.




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

Re: [Talk-GB] Are Northern Ireland, Wales & England 'states'?

[Colin Smale]

On 2017-08-22 13:50, Andy Townsend wrote:

> On 22/08/2017 12:23, Colin Smale wrote:
> What would a "local" answer?
> 
> Good luck getting a consistent answer to that :)
> 
> http://ma3t.co.uk/euanmills/euanmills/tifd.html

Wow, I rest my case... 

Although he seems to have asked people who were simply present in the
area, and not local residents.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Are Northern Ireland, Wales & England 'states'?

[Andy Townsend]

On 22/08/2017 12:23, Colin Smale wrote:


 What would a "local" answer?



Good luck getting a consistent answer to that :)

http://ma3t.co.uk/euanmills/euanmills/tifd.html

Best Regards,

Andy

(and apologies in advance for anyone upset by small-font profanity in 
the link)


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

Re: [Talk-GB] Are Northern Ireland, Wales & England 'states'?

[Dave F]

The main one I came across was is_in:continent=Europe. I asked why there 
wasn't one. The conclusion was no one could agree where the boundary 
actually was. Saying that, I'm unsure if specifying 
is_in:continent=Europe is that beneficial.


Also many local authority political ward boundaries aren't in the database.

DaveF

On 21/08/2017 20:00, Andrew Hain wrote:
Should we go a bit further and strip out all is_in tags not used by 
Nominatim across Britain (which may mean all of them), or are there 
other uses we should consider? The community in France did that when 
they finished mapping communes.


--
Andrew

*From:* Dave F 
*Sent:* 20 August 2017 22:57:06
*To:* Andrew Black; Talk-GB@openstreetmap.org
*Subject:* Re: [Talk-GB] Are Northern Ireland, Wales & England 'states'?
I will revert

DaveF

On 12/08/2017 22:39, Andrew Black wrote:



On 12 August 2017 at 13:12, Dave F > wrote:


Hi
I'm unsure if Northern Ireland, Wales & England should be tagged
as 'states'.

A new user's changeset comment:
Adding more info. is_in:country_code was missing. Also classified
Northern Ireland as a state so it appears in the same priority as
Wales. Was unclassified before


Doesn't make sense to me.

"A high-level sub-national political entity 
(Wikipedia-16px.png Federated state 
) in several large 
countries such as USA ("State"), Australia ("State"), Canada 
("Province"). May also be applicable in other countries and 
languages, "Provincia", "Estado", "Land" - whether is should be used 
is up to you and mappers in your own country."


 We are not a federated country. Suggest we revert it. Why is Wales a 
state in the first place.




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

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

[Marc Gemis]

Did you try with e.g. MapFactor Navigator, which has settings for your
preference of 8 road categories + maxspeed inside & outside towns ?
Just being curious.

regards

m

On Tue, Aug 22, 2017 at 1:13 PM, Lester Caine  wrote:
> On 22/08/17 11:41, Colin Smale wrote:
>> I agree,  classification should be largely irrelevant to routing.
>> Routing needs timings from node to node, which are best derived from
>> bendiness, number of lanes, junctions etc and then capped to the legal
>> maximum. A four-lane secondary, primary, trunk or motorway will all have
>> the same effective speed in the absence of bends and junctions.
>
> The problem here is that most routing systems use the highway= tag as
> the initial key to defining the 'defaults' for a link and the delay
> elements added moving from one type of road to another. I am convinced
> there is a problem with the tagging of the B4632 which is preventing it
> from being seen as an alternative to the A46 10 mile detour but as yet
> I've not spotted anything wrong. Shortest routing will pick it up, but
> then avoids the M40/M6 for the next stage :( It's not just OSM routing
> that gives problems, other routing engines are showing similar detours
> around local 'shortcuts' ... so even within a single country
> harmonization is a problem ...
>
> --
> 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 ?

[Colin Smale]

The road classification suggests a default maxspeed, in the absence of
more explicit information. I don't understand why junction penalties
should be dependent on the road classes, and not on physical
characteristics. I guess this is just a heuristic which can be useful if
you don't have the full picture. 

I would like to take a closer look at your example route... Can you give
start and end locations?

--colin 

On 2017-08-22 13:13, Lester Caine wrote:

> On 22/08/17 11:41, Colin Smale wrote: 
> 
>> I agree,  classification should be largely irrelevant to routing.
>> Routing needs timings from node to node, which are best derived from
>> bendiness, number of lanes, junctions etc and then capped to the legal
>> maximum. A four-lane secondary, primary, trunk or motorway will all have
>> the same effective speed in the absence of bends and junctions.
> 
> The problem here is that most routing systems use the highway= tag as
> the initial key to defining the 'defaults' for a link and the delay
> elements added moving from one type of road to another. I am convinced
> there is a problem with the tagging of the B4632 which is preventing it
> from being seen as an alternative to the A46 10 mile detour but as yet
> I've not spotted anything wrong. Shortest routing will pick it up, but
> then avoids the M40/M6 for the next stage :( It's not just OSM routing
> that gives problems, other routing engines are showing similar detours
> around local 'shortcuts' ... so even within a single country
> harmonization is a problem ...___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] Are Northern Ireland, Wales & England 'states'?

[Colin Smale]

Let's have some use cases out on the table... if my location is
{lat,lon}, where am I? What answer am I expecting? Postal address? Town
or other settlement? The local council? What would a "local" answer? 

In the UK, the hierarchy of admin boundaries is incomplete and imperfect
- there are unparished areas, and combined authorities for example.
There are so many black holes in the UK - where you are in no-mans-land
"between A and B but in neither." If nobody lives there, is it actually
necessary to be able to say where you are? 

If you ask people where they live, they will probably talk about the
county level and the settlement/town/city, but the informal boundaries
of these settlements will likely not follow the administrative
boundaries. In fact, it may not be possible to agree a polygon with a
sharp boundary of what constitutes a settlement with a given name. Most
place=* polygons in OSM just follow the boundary of the built-up area. 

So I see a possible role for is_in - to help out geocoding where
geometrical methods lead to an undesirable (though accurate) result.

//colin 

On 2017-08-22 12:57, Dave F wrote:

> This is a reply to a Q. I posed on Talk. Nominatum clearly prefer boundaries 
> to is_in & say it's not heavy processing:
> https://lists.openstreetmap.org/pipermail/talk/2016-August/076596.html
> 
> As UK boundaries are sure be updated in OSM, keeping the secondary is_in 
> 'cleanly managed' will be a major task.
> 
> On 22/08/2017 09:38, Lester Caine wrote: On 12/08/17 13:12, Dave F wrote: I 
> also think the 'is_in:country_code' along with all 'is-_in' tags are
> redundant if there's a boundary tag.. In the past I thought that the is_in 
> element was something of a problem,
> but it does have a place when one remembers that OSM is all about the
> data. "if there's a boundary tag" is the problem here if one is
> extracting a set of data? Processing a number of boundaries around a set
> of objects takes time, while cleanly managed is_in:admin_area with a
> proper hierarchy allows a much quicker lookup of information such as -
> in the case of the the UK - parliamentary boundaries, wards, historic
> county, NHS admin area and so on without having to physically draw every
> fine detail of these ever changing boundaries. BUT it only works well if
> there is a well defined hierarchy so tagging is_in:gb-ward
> http://geoportal.statistics.gov.uk/datasets/417e93f21c5c419283ac23abc8eedcce_0
> gives all this data in a format we can freely use as with the other
> 'boundary' data.
> 
> It is just a pity that 'postcode' is so badly organised that it quite
> regularly straddles these other boundaries, but is_in:gb-postcode would
> remove the need to add all of the associated address data to every
> object on a particular street, and for the vast majority of postcodes it
> WOULD also identify all of the other is_in: data at a higher level. It
> just needs an object defining is:gb-postcode and is:gb-ward to provide
> all the hierarchy ... without overloading the server with searches for
> all of the boundaries intersecting the original dataset?
> 
> Of cause I am also still looking to maintain access to historic data,
> and this model makes it easy to check start and end dates of
> is:gb-postcode and is:gb-ward without having to maintain all of those
> boundaries actually in the base dataset - something which the majority
> of users seems to have decided against :(

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

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

[Lester Caine]

On 22/08/17 11:41, Colin Smale wrote:
> I agree,  classification should be largely irrelevant to routing.
> Routing needs timings from node to node, which are best derived from
> bendiness, number of lanes, junctions etc and then capped to the legal
> maximum. A four-lane secondary, primary, trunk or motorway will all have
> the same effective speed in the absence of bends and junctions.

The problem here is that most routing systems use the highway= tag as
the initial key to defining the 'defaults' for a link and the delay
elements added moving from one type of road to another. I am convinced
there is a problem with the tagging of the B4632 which is preventing it
from being seen as an alternative to the A46 10 mile detour but as yet
I've not spotted anything wrong. Shortest routing will pick it up, but
then avoids the M40/M6 for the next stage :( It's not just OSM routing
that gives problems, other routing engines are showing similar detours
around local 'shortcuts' ... so even within a single country
harmonization is a problem ...

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

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

[Lester Caine]

On 22/08/17 11:16, djakk djakk wrote:
> Lester, why the little "main road" was not tagged as a tertiary road ?

The 'minor' roads are 'both secondary and tertiary' ... one example used
to be the 'trunk' road A46 but is now 'secondary' B4632, so many of the
routers using OSM data use the 'new' A46 which results in a 10 mile
detour :( I was hitting the same problem in Wales! ... the main through
route A66 is just that and not designed for local journeys. Selecting
'shortest route' often hits the 'single track' roads one DOES want to
avoid ...

> 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 !). 

Single carriageway roads here are 60MPH out of town and 30MPH in town
but I'm not sure OSMAND actually understands that anyway applying 20MPH
limit to all secondary and tertiary roads? The routes I am talking about
are tertiary roads with 40 and 50MPH speed limit sections ... I do add
them in where I find them, but many were not showing in North Wales :(

But I see no way to harmonization world wide. Even for just 'trunk'. The
'rules' for a country or area need to cover the differences that apply
in that area? Just as the routing rules need to know France is Left Hand
and UK is Right ... with different default speed limits.

> Le mar. 22 août 2017 à 11:16, Lester Caine  > 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

Re: [Talk-GB] [Talk-gb-london] New OSM London Meetup - Invite

[Andres Muniz Piniella]

Hi,
new to OSM edit. I live in an estate TW10 7NY. Currently 192 homes and
it is at risk of redevelopment in to make 425 homes. There is also a
community project to document historical features so I want to thank
you for this guidance. It will be helpful to edit entries. 
Regards, 
Andres
On Mon, 2017-08-21 at 19:42 +0100, SK53 wrote:
> My normal practice is to map the estate as a separate landuse area
> and name that. One example I've done fairly recently in this way is
> the Whittington Estate, Highgate. 
> 
> My view is that named estates vary in size & local perception too
> much for a single place=* usage. Most London ones will be perceived
> to be in a particular suburb (even quite large ones) so I don't think
> the suburb tag is likely to be appropriate. They are usually very
> well delineated, both on the ground and in terms of architecture.
> Several distinct estates may also form a coherent neighbourhood. 
> 
> Recent examples I've looked at (largely inspired by John Boughton who
> blogs & tweets as Muncipal Dreams):
> 
> Ossulton Estate (Somertown): name attached to buildings. 
> Old Oak Estate (Acton/Hammersmith): not mapped. There are two early
> 20C estates either side of Du Cane road.
> Progress Estate (Eltham): added as an area.
> New Addington (LB of Croydon, but a place in its own right). John
> Gringrod's new book Outskirts, about the Green Belt, features this
> estate extensively. He grew up there.
> A couple of Islington estates (perhaps Andover) which were anonymised
> in a 1970s book. I don't have the reference to hand.
> Delineating the estates is very useful for a number of reasons
> associated with the study of these areas: history, architecture,
> urban planning, sociology etc. Detailed mapping may be of direct
> assistance for residents associations (the sort of thing Tom has done
> in the past). Of course the ideal would be that mapping involved
> people who live on the estates. Plenty of the modern academic
> literature comes from people who grew up on council estates.
> I would recommend seeing what has been written about these places as
> a way of informing ones mapping. There's often surprisingly detailed
> information: its not unusual for some older people living on these
> estates to have known them all their lives. Or their children return
> frequently: Ian Waites accounts and photos of the Middlefield Estate
> in Gainsborough show what can be done.
> Other writers worth reading for perspectives relevant to mapping
> stuff on OSM include: Lynsey Hanley ("Estates"), Owen Hatherley
> (mainly in articles and all over the place), Chris Matthews
> (Nottingham & other East Midland estates), Lisa Mckenzie (who
> espouses "narrative from within"). These are all in one way or other
> left-wing.
> Regards,
> 
> Jerry
> 
> On 21 August 2017 at 16:49, Tom Chance  wrote:
> > Hi Nicolas,
> > 
> > I think that could be really valuable. One of the first mapping
> > parties I attended was one I helped Harry organise, to map north
> > Peckham when the whole area was a blank space on the map, and in
> > particular to add more detail for roads and footpaths through
> > estates that were usually just shown as gaps in other maps. I also
> > helped map the trees on the Heygate Estate before demolition
> > started, which is great to have as an archive of what was there
> > before the developers reneged on promises and cut some of the best
> > specimens down.
> > 
> > Just a few points/questions...
> > 
> > 1. Presumably the data is coming from people's local knowledge, so
> > there aren't any copyright issues? What's the underlying map people
> > are adding them to - OSM? Google maps? That might create a
> > copyright issue. I know there are maps of London council estates
> > knocking around that are based on Ordnance Survey data.
> > 
> > 2. Someone would then need to go through, one by one, and check
> > whether the estate's name is already in the database before adding
> > the missing names. There are already lots in OSM, so it would be
> > good to avoid adding duplicates.
> > 
> > 3. I'm not sure we've ever settled on the right place= value for
> > estates. It's some years since I was really actively mapping -
> > these days I just maintain my immediate area. But would it be
> > place=neighbourhood, place=locality, place=estate, something else?
> > 
> > 4. Some estates are entered as nodes, others as areas, and some
> > areas are landuse=residential while others are just given the
> > estate name. Again, this might be a good opportunity to get a
> > consistent approach?
> > 
> > Best wishes,
> > Tom
> > 
> > Tom Chance
> > Housing policy and programmes consultant
> > m: 07866 447 075
> > w: http://tomchance.org
> > 
> > On 17 August 2017 at 12:18, Nicolas Fonty 
> > wrote:
> > > Hi Bjoern
> > > 
> > > Not yet in OSM.  For the moment we are just locating their
> > > approximative centre with coordinates + their name.
> > > And that would be 

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

[Colin Smale]

I agree,  classification should be largely irrelevant to routing.
Routing needs timings from node to node, which are best derived from
bendiness, number of lanes, junctions etc and then capped to the legal
maximum. A four-lane secondary, primary, trunk or motorway will all have
the same effective speed in the absence of bends and junctions.

//colin 

On 2017-08-22 10:47, Lester Caine wrote:

> 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?___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-gb-westmidlands] Research contributions needed www.3dosm.com

[Alfie Kelly]

Hello,

I am an M.Sc. researcher with the University of Nottingham and am currently 
conducting a research study regarding the potential for 3D building data 
collection by OSM users and the crowd.

I am particularly interested in people’s motivations for collecting 3D building 
information and potential barriers to data collection and editing. I am also 
interested in the potential for semantic enrichment (e.g. building materials 
etc.) of buildings via publicly available imagery (satellite and street view).

What can you do to help?

I have created a website to collect some data from the OSM community. I would 
really appreciate it if you could visit www.3dosm.com and complete the 
questionnaire and 3D building surveys.

Who is this research targeted at?

Anybody who is interested in OpenStreetMap and has either contributed 3D 
information or might like to contribute 3D information in the future. Knowledge 
of 3D surveying isn’t necessary and I would encourage anybody with a passion 
for OSM to take part.

Am I anonymous?

All forms you complete (and the resulting data) is completely anonymous and no 
IP addresses or personal information will be stored or processed.

Thank you so much for taking the time to read this. I am passionate about 
sustainable crowd sourced solutions to data collection, and I really hope that 
with your help this research can support the future of 3D OSM!

Alfie





This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

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

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr

[Christian Rogel]

> Le 22 août 2017 à 11:46, PanierAvide  a écrit :
> +1, le Japon c'est pas la porte à côté ;-) On va sortir d'ici peu (fin de 
> semaine au plus tard) un billet sur le site openstreetmap.fr pour faire un 
> retour sur ce qui s'y est passé. En attendant, un certain nombre de photos 
> sont sur Twitter [1] et Flickr [2].
> 
> Adrien.
> 
> [1] https://twitter.com/hashtag/sotm?f=tweets=default=hash
> [2] https://www.flickr.com/photos/tags/sotm2017
> 
> Le 21/08/2017 à 00:59, Vincent de Château-Thierry a écrit :
>>> On attend les retours de ceux qui ont été au State of the Map qui est en 
>>> cours au Japon, mais, personne n’a pensé en en parler.
>> 
>> Il y aura ! Laisse leur le temps de rentrer ;)

Salut, Adrien,
On attend le CR et, donc, un petit résumé ici sera bienvenu, comme je le disais.
Ma remarque concernait l'avant SotM 2017.
Ceux qui ne sont pas dans la partie organisée de la communauté n'avaient aucun 
moyen de savoir qu'il allait avoir lieu, à moins de s'abonner à HebdoOSM 
http://www.weeklyosm.eu/fr/archives/9374 S'abonner via col. de droite "Suscribe 
to OSM".
On devrait y retrouver bientôt l'annonce de Tagging-fr.


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

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 
a écrit :

>
>
> sent from a phone
>
> > On 21. Aug 2017, at 22:09, djakk djakk  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

[OSM-talk-fr] [ortho] serveur scratch osm.tetaneutral.net

[Laurent GUERBY]

Bonjour,

Le serveur "scratch" orthophoto pour faire des tests de dimensionnement
est en place et les cles ssh root aussi (manque celle de Christian, pas
reçue ?).

https://pad.tetaneutral.net/p/osm
<<
* Debian 9 stretch amd64
* Ryzen 1700 8C/16T 3 GHz
* 64G de RAM  (swap desactivé)
* Disques 5 SSD

root@h9:~# df -h
Filesystem  Size  Used Avail Use% Mounted on
/dev/sde2   165G  1.1G  164G   1% /
/dev/sda962G   77M  962G   1% /scratch/t1
/dev/sdd962G   77M  962G   1% /scratch/t2
/dev/sdb110G   61M  110G   1% /scratch/s1
/dev/sdc110G   61M  110G   1% /scratch/s2

Usage des disques SSD :

/ => uniquement pour package et config
/scratch/t1 et t2 => disques 1 TB mais avec endurance write
relativement faible = 320 TBW, a utiliser pour données qui ne vont pas
beaucoup bouger ou qui ne rentrent pas ailleurs
/scratch/s1 et s2 => disques 120GB mais avec tres grande endurance
write = 690 TBW a utiliser pour les (petites) BDD, calculs
intermediaires et transformations de fichiers
>>

Pour le moment c'est en 1 Gbit/s donc ~ 90-100 Mo/s wget sur online et
OVH, la carte 10G est dans la machine mais pas encore configurée.

Sincèrement,

Laurent

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

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  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-fr] Création de la liste OSM tagging-fr

[PanierAvide]

+1, le Japon c'est pas la porte à côté ;-) On va sortir d'ici peu (fin 
de semaine au plus tard) un billet sur le site openstreetmap.fr pour 
faire un retour sur ce qui s'y est passé. En attendant, un certain 
nombre de photos sont sur Twitter [1] et Flickr [2].


Adrien.

[1] https://twitter.com/hashtag/sotm?f=tweets=default=hash
[2] https://www.flickr.com/photos/tags/sotm2017


Le 21/08/2017 à 00:59, Vincent de Château-Thierry a écrit :
On attend les retours de ceux qui ont été au State of the Map qui est 
en cours au Japon, mais, personne n’a pensé en en parler.


Il y aura ! Laisse leur le temps de rentrer ;)



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

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

[Martin Koppenhoefer]

sent from a phone

> On 21. Aug 2017, at 22:09, djakk djakk  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 ?

[Martin Koppenhoefer]

sent from a phone

> On 19. Aug 2017, at 21:29, Marc Gemis  wrote:
> 
> 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.


in Germany and Italy trunk is used for roads similar to motorways which aren't 
legally motorways though, e.g. with ramps and without grade level 
intersections, often dual carriage ways, but which might (exceptionally) permit 
pedestrians or bikes.

Roads which are restricted to specific vehicle classes (e.g. no pedestrians, no 
slow vehicles like bicycles or mopeds or tractors) are additionally tagged with 
motorroad=yes.

This differentiation has proven very versatile in Germany and Italy basically 
leaving no tagging gaps for road classification.

cheers,
Martin 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Lester Caine]

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

Re: [Talk-GB] Are Northern Ireland, Wales & England 'states'?

[Lester Caine]

On 12/08/17 13:12, Dave F wrote:
> I also think the 'is_in:country_code' along with all 'is-_in' tags are
> redundant if there's a boundary tag..

In the past I thought that the is_in element was something of a problem,
but it does have a place when one remembers that OSM is all about the
data. "if there's a boundary tag" is the problem here if one is
extracting a set of data? Processing a number of boundaries around a set
of objects takes time, while cleanly managed is_in:admin_area with a
proper hierarchy allows a much quicker lookup of information such as -
in the case of the the UK - parliamentary boundaries, wards, historic
county, NHS admin area and so on without having to physically draw every
fine detail of these ever changing boundaries. BUT it only works well if
there is a well defined hierarchy so tagging is_in:gb-ward
http://geoportal.statistics.gov.uk/datasets/417e93f21c5c419283ac23abc8eedcce_0
gives all this data in a format we can freely use as with the other
'boundary' data.

It is just a pity that 'postcode' is so badly organised that it quite
regularly straddles these other boundaries, but is_in:gb-postcode would
remove the need to add all of the associated address data to every
object on a particular street, and for the vast majority of postcodes it
WOULD also identify all of the other is_in: data at a higher level. It
just needs an object defining is:gb-postcode and is:gb-ward to provide
all the hierarchy ... without overloading the server with searches for
all of the boundaries intersecting the original dataset?

Of cause I am also still looking to maintain access to historic data,
and this model makes it easy to check start and end dates of
is:gb-postcode and is:gb-ward without having to maintain all of those
boundaries actually in the base dataset - something which the majority
of users seems to have decided against :(

-- 
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-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-in] Tagging service roads of National Highways

[Naveen Francis]

tagging guidelines for NHs
https://wiki.openstreetmap.org/wiki/India:Tags/Highway

On 22 August 2017 at 12:18, Srihari Thalla  wrote:

> Hi,
>
> The secondary tag seems more appropriate for the area I have shared.
> Thanks for the Wiki link. I'll update the roads.
>
> On Tue, 22 Aug 2017 at 12:06 I Chengappa  wrote:
>
>> hi
>>
>> It definitely should not be trunk_link.
>>
>> The advice at https://wiki.openstreetmap.org/wiki/Frontage_road is that
>> it should be tagged as a minor road as compared to the major road. The
>> tagging level should depend on its function in local connectivity i.e. how
>> important it is in connecting local settlements. I think most of them could
>> reasonably be tagged as tertiary or secondary roads.
>>
>> Thanks,
>>
>> On 19 August 2017 at 10:15, Srihari Thalla 
>> wrote:
>>
>>> Hi!
>>>
>>> Some of the major National Highways (like Asian Highways[1]) have
>>> service roads running in parallel. What is the standard tagging of these
>>> roads?
>>>
>>> I have tagged them as "trunk_link" [2] but I am not sure if this is the
>>> one followed by others.
>>>
>>> [1] - http://www.openstreetmap.org/way/471481188
>>> [2] - http://www.openstreetmap.org/way/421844986
>>>
>>> Cheers,
>>> Srihari
>>> --
>>> Cheers,
>>> Srihari
>>>
>>> ___
>>> Talk-in mailing list
>>> Talk-in@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-in
>>>
>>>
>> ___
>> Talk-in mailing list
>> Talk-in@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-in
>>
> --
> Cheers,
> Srihari
>
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-in
>
>
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [Talk-cz] FYI: Body záchrany v pražských lesích

[Marián Kyral]

-- Původní e-mail --
Od: Jan Martinec 
Komu: OpenStreetMap Czech Republic 
Datum: 14. 8. 2017 16:19:26
Předmět: [Talk-cz] FYI: Body záchrany v pražských lesích
"Ahoj,

Lesy Prahy zveřejnily sadu "Bodů záchrany" (tabulky typu "jsem u bodu
AA007 a hoří tady"); zatím jsem je zmapoval v kunratickém lese jako
highway=emergency, ale netroufám si to mapovat "od stolu" podle těch
přehledových plánků.
http://www.prazskypatriot.cz/navstevnikum-prazskych-lesu-je-nove-k-dispozici
-29-bodu-zachrany/

(btw zajímavé, že číslování začíná od ref AA003, že by měli někde "cvičný"?)
"






S těmi body se teď docela často potkávám. Dle https://lesycr.cz/tiskova-
zprava/ve-statnich-lesich-bude-od-rijna-2-500-bodu-zachrany/ je všechny
evidují hasiči. Nedalo by se nějak k tomu datasetu dostat? Minimálně aby
člověk věděl, kde na ně může narazit a zajít to zmapovat.





Marián
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

[Talk-us] Whole-US Garmin Map update - 2017-08-20

[Dave Hansen]

These are based off of Lambertus's work here:

http://garmin.openstreetmap.nl

If you have questions or comments about these maps, please feel
free to ask.  However, please do not send me private mail.  The
odds are, someone else will have the same questions, and by
asking on the talk-us@ list, others can benefit.

Downloads:

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2017-08-20

Map to visualize what each file contains:


http://daveh.dev.openstreetmap.org/garmin/Lambertus/2017-08-20/kml/kml.html


FAQ



Why did you do this?

I wrote scripts to joined them myself to lessen the impact
of doing a large join on Lambertus's server.  I've also
cut them in large longitude swaths that should fit conveniently
on removable media.  

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2017-08-20

Can or should I seed the torrents?

Yes!!  If you use the .torrent files, please seed.  That web
server is in the UK, and it helps to have some peers on this
side of the Atlantic.

Why is my map missing small rectangular areas?

There have been some missing tiles from Lambertus's map (the
red rectangles),  I don't see any at the moment, so you may
want to update if you had issues with the last set.

Why can I not copy the large files to my new SD card?

If you buy a new card (especially SDHC), some are FAT16 from
the factory.  I had to reformat it to let me create a >2GB
file.

Does your map cover Mexico/Canada?

Yes!!  I have, for the purposes of this map, annexed Ontario
in to the USA.  Some areas of North America that are close
to the US also just happen to get pulled in to these maps.
This might not happen forever, and if you would like your
non-US area to get included, let me know. 

-- Dave


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

Re: [OSM-fi] Finnish National Registry of Social and Health care Providers as POIs

[Äijälä Tero]

Hi,

I created the page as suggested here: 
https://wiki.openstreetmap.org/wiki/ODA/Finnish_SOTE_registry_import. Will try 
a smaller upload first for one city, for example Tampere.
There are definitely existing POIs for many of the service providers, uploaded 
by individual users or the organizations themselves.
For completeness having an “official” set of POIs coming from the SOTE registry 
would have some benefit perhaps, on the other hand this would probably result 
in a slow update cycle.

How would you see this working best? We could probably upload now only the 
missing POIs, and outside this process instruct people on how to maintain their 
location going forward.

Br,

Tero

Lähettäjä: Eduardo Gonzalez 
Päivämäärä: maanantai 21. elokuuta 2017 klo 9.01
Vastaanottaja: Äijälä Tero , "impo...@openstreetmap.org" 
, "talk-fi@openstreetmap.org" 

Aihe: [OSM-fi] Finnish National Registry of Social and Health care Providers as 
POIs

Hi Tero,

have you checked this guidelines about importing? 
http://wiki.openstreetmap.org/wiki/Import/Guidelines (and 
http://wiki.openstreetmap.org/wiki/Import/Plan_Outline).

Especially step 4 where it is asked to create an OSM wiki page documenting your 
plan. There is a nice example made by HSL for importing Swedish street names 
http://wiki.openstreetmap.org/wiki/Digitransit/Helsinki_region_Swedish_road_names_import
 (which follows the Plan_Outline mentioned above). Your github page looks 
somehow like that but the OSM recommendation is to document to the OSM wiki.

As for the import itself, testing in a small area and reviewing the results 
before making an import for the whole dataset may be a good way to start. But 
surely you have planned for that already. A more specific check that comes to 
mind is to check for already existing POIs that may already contain that 
information (and not import double POIs).

Cheers,
Eduardo


Subject: [OSM-fi] Finnish National Registry of Social and Health care Providers 
as POIs
Message-ID: 
>
Content-Type: text/plain; charset="utf-8"
Hey OSM,
I'd like to propose an import of the Finnish National Registry of social and 
health care providers.
National Institute for Health and Welfare (THL) maintains a registry for all 
public and private social and health care providers in Finland.
The data is available under the CC BY 4.0 license. THL has given permission to 
use their data, provided they are listed on the copyright page as a data source.
My intention is to use the service provider information available from the 
registry (name, address, provider type: social/healthcare), geocode the 
addresses to coordinates, transform the data to JOSM POI format and import the 
set to OSM.
See the readme for more details:  https://github.com/omahoito/osm-import
Br,
Tero
___
talk-fi mailing list
talk-fi@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fi

Re: [Talk-in] Tagging service roads of National Highways

[Srihari Thalla]

Hi,

The secondary tag seems more appropriate for the area I have shared. Thanks
for the Wiki link. I'll update the roads.

On Tue, 22 Aug 2017 at 12:06 I Chengappa  wrote:

> hi
>
> It definitely should not be trunk_link.
>
> The advice at https://wiki.openstreetmap.org/wiki/Frontage_road is that
> it should be tagged as a minor road as compared to the major road. The
> tagging level should depend on its function in local connectivity i.e. how
> important it is in connecting local settlements. I think most of them could
> reasonably be tagged as tertiary or secondary roads.
>
> Thanks,
>
> On 19 August 2017 at 10:15, Srihari Thalla 
> wrote:
>
>> Hi!
>>
>> Some of the major National Highways (like Asian Highways[1]) have service
>> roads running in parallel. What is the standard tagging of these roads?
>>
>> I have tagged them as "trunk_link" [2] but I am not sure if this is the
>> one followed by others.
>>
>> [1] - http://www.openstreetmap.org/way/471481188
>> [2] - http://www.openstreetmap.org/way/421844986
>>
>> Cheers,
>> Srihari
>> --
>> Cheers,
>> Srihari
>>
>> ___
>> Talk-in mailing list
>> Talk-in@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-in
>>
>>
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-in
>
-- 
Cheers,
Srihari
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [OSM-talk] Macromapping problems

[Oleksiy Muzalyev]

On 22.08.17 01:42, Daniel Koć wrote:

...
That's probably why we have Asia mapped as a node in the middle of 
nowhere:


http://www.openstreetmap.org/node/36966065
...


Good morning Daniel,

This node is in the Irkutsk Oblast [1]. I was born and lived there for a 
while.


Irkutsk Oblast has got an area larger than the area of say Germany, 
California, or France. The nature, woods, rivers, lakes, etc. there is 
amazing. It is one of the most beautiful regions of the planet.


Actually the whole territory at and around this node is coniferous 
forest which is not mapped yet, and that is why also not visible on the 
macro-map.


I remember that when I as a child had to move with my parents to a city 
in an European part I was surprised that there were so little wild 
nature around a city and so many agriculture fields.


[1] https://en.wikipedia.org/wiki/Irkutsk_Oblast

With best regards,

Oleksiy


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

Re: [Talk-in] Tagging service roads of National Highways

[I Chengappa]

hi

It definitely should not be trunk_link.

The advice at https://wiki.openstreetmap.org/wiki/Frontage_road is that it
should be tagged as a minor road as compared to the major road. The tagging
level should depend on its function in local connectivity i.e. how
important it is in connecting local settlements. I think most of them could
reasonably be tagged as tertiary or secondary roads.

Thanks,

On 19 August 2017 at 10:15, Srihari Thalla  wrote:

> Hi!
>
> Some of the major National Highways (like Asian Highways[1]) have service
> roads running in parallel. What is the standard tagging of these roads?
>
> I have tagged them as "trunk_link" [2] but I am not sure if this is the
> one followed by others.
>
> [1] - http://www.openstreetmap.org/way/471481188
> [2] - http://www.openstreetmap.org/way/421844986
>
> Cheers,
> Srihari
> --
> Cheers,
> Srihari
>
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-in
>
>
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in