Re: [OSM-ja] 平泉でMapllary

[Tomomichi Hayakawa]

Tomです。

１３日に中尊寺に行ってきました。

第二弾、今から行って、マピラリってきます。
今日は、毛越寺あたりかな。
シータってるオッサン見たら、声かけてね。

2019年3月12日(火) 16:34 Tomomichi Hayakawa :
>
> Tomです。皆さんこんにちは。
>
> 季節も良くなってきましたし、
> 今週末から来週末にかけて時間が取れそうなので、
> 平泉にMapillaryしに行こうかと思います。
>
> 一緒に行けそうな人がいましたら、声かけていただけると嬉しいです。
> とりあえず今週末を予定していますが、天気次第で変更もあります。
>
> 平日でも、朝の目覚めが良くて、天気も良かったら、気分で行くかもです。
>
> Theta 立てて、GoPro胸に付けてるおっさんがいたら、声かけてやってください。
> それは高い確率で、僕です。
>
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> はやかわ ともみち (Tomomichi Hayakawa)
> tom.hayak...@gmail.com
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
はやかわ ともみち (Tomomichi Hayakawa)
tom.hayak...@gmail.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

[OSM-ja] 初の関西3/30開催Mapillary Meetup Nara

[ikiya]

ikiyaです。

OpenStreetMapのマッピングツールとして注目を集めるMapillary のユーザー交流会が3月30日（土）奈良女子大で開催されます。
Mapillary Meetup初の関西開催となります。講演や事例発表、技術発表、クイズ、パネルデスカッションなどが予定されています。

◆開催日：2019年 3月30日（土）10時開会
◆会場： 奈良女子大学ラウンジ
（地図）https://osm.org/go/7QGTObJfB?m=
◆主催/共催：
・奈良女子大学文学部人文社会学科地域環境学コース
・Mapillary Contributors in Japan
◆後援：OSGeo財団日本支部
◆参加費：無料
（昼食、懇親会費用は自己負担願います。）　

参加登録はこちらです。
https://atnd.org/events/104192


（プログラム）

・Mapillaryを用いたオープンなストリート画像共有の大いなる可能性と課題
　　　西村雄一郎（奈良女子大学 人文科学系 准教授）

・事例発表「マピラリってます！」山下康成
・事例発表「ミリオネアの日常」目黒純
・事例発表「撮影の最新事例（仮」渡邉剛広

・Mapillaryを支えるデータ＆アルゴリズム＆チャレンジ
　　瀬戸寿一（東京大学空間情報科学研究センター 特任講師）

・スペシャル企画「世界一周Mapillaryクイズ」
（スウェーデンから届いた記念賞品）

・THETA製品紹介とストリートビューへの応用
　　Michael Usami（RICOH THETA事業部）
・Mapillary APIで無駄に色々な計算結果を出してみる
　　市川博行 （市川電算CEO）

今回、RICOH THETA事業部から個人参加での発表協力をいただいて
興味あるTHETA最新情報についても触れられる機会となっています。
また、ストリートビューにおけるトッププレイヤーの皆様も参加される予定です。

最新かつ熱いテーマでユーザー交流会が行えると思います。
ぜひ、この機会にご参加ください。

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

Re: [Talk-GB] Bridleway or track?

[Rob Nickerson]

Martin wrote:

>But presumably the designers of OSM intended only one of these meanings
>for the highway tag. But I still don't know whether it is physical
>appearance or legal status. The wiki seems to be mixed up on this. For
>example:
>
> 

Hi Martin,

I really think you are over-thinking it. We have to remember that OSM was
not "designed", rather it evolved. In the early days it was UK centric and
when highway tag were being developed the proposer looked at the system of
roads and rights of way we have in the UK. Hence highway=motorway,
highway=trunk, ... highway=bridleway were selected to match how things were
often *referred* to in the UK. As it happens the way we in the UK refer to
things tends to align closely to the legal status (or some other official
status). Over time some of this has become less relevant - for example the
highway=trunk tag is of reducing relevance due to "de-trunking" of roads
(see wikipedaia [1]).

The bigger issue however came when OpenStreetMap grew globally. The way
that other countries refer to things doesn't always match us. As examples
"motorway" is not a term used globally, the concept of "trunk" roads is
alien to some people and many counties do not have the 4 classes of public
right of way that we do. As such other tags started to come in to use. In
particular the highway=path tag.

Now this new global tagging caused confusion in the UK as some tags seem to
be very similar (e.g highway=path and highway=footway). We also found
people were mapping using highway=footway when it was not an explicit
public right of way.

After much back and forth the UK settled on the designation=* tag as the
right way to signify the legal status (e.g. designation=public_footpath).
This is described in the link I previously shared [2]. This solution means
that people can use highway=path, highway=footway, highway=trunk (or
whatever else) and add the designation=public_footpath tag to indicate it's
legal status. It is a win for the community:

- those adding designation=public_footpath are doing so intentionally to
mark the legal status.
- we do not have to "police" the use of highway=footway; as in, there is no
need to contact people to tell them to only use highway=footway if it is a
public right of way (this option of trying to "police" the use of a tag was
never going to be a viable solution).

As such we evolved with the times and use highway tag to mark what you
*observe* (surely this is both physical appearance AND evidence of use
because the evidence of use IS observed physical appearance unless you are
setting up camera traps!).

The one oddity it leaves is that highway=path and highway=footway are very
similar. Noting my point above that it is not possible to "police" use,
these tags started to be used interchangeably. A few years later the
maintainers of the default map style (OSM Carto) made an update to the
style of the map so that highway=footway and highway=path are shown
identically. They then started showing a difference for surface. So if we
map highway=footway/path and add a surface=paved tag then it renders
differently. Again this is a win for the community as it encourages use of
the surface tag which provides valuable context.

So in summary, please follow the principle of "first map the feature" and
then "add the legal designation". Map the feature according to what you
observe (again I note that surely this is the same as the evidence of use).

Aside: A public footpath may not have big signs of use. If it's just a few
people using it occasionally then you won't get the marks in the ground
that you observe on some of our more heavily used paths. Consider this and
the time of year (paths overgrown in spring/summer may be cut back and
accessible again later in the year) before picking highway=disused. Disused
should be a rare exception.

I hope this helps. Key thing is to not get hung up on the history of how we
got here. Just go for it, use the additional tags (designation and surface)
to add valuable info and have fun mapping :-)

[1] https://en.wikipedia.org/wiki/Trunk_road#De-trunking:_United_Kingdom
[2] https://wiki.openstreetmap.org/wiki/UK_access_provisions

Best regards,
*Rob*
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Bridleway or track?

[Martin Wynne]

or record its actual usage? 


Yes, in as much as "record its actual usage" is essentially the same as 
"describe its usage".


Hi Andy,

I was meaning "describe its physical appearance".

For example, for:

 http://85a.uk/track_query_960x648.jpg

I could tag it as:

highway=track  (physical appearance), or

highway=footway (legal status), or

highway=disused (evidence of use).

But presumably the designers of OSM intended only one of these meanings 
for the highway tag. But I still don't know whether it is physical 
appearance or legal status. The wiki seems to be mixed up on this. For 
example:


1. highway=secondary (*legal status* - B road, and physical appearance, 
condition, etc. is irrelevant).


Actual width, etc., to be set as separate (optional) tags.

Whereas:

2. highway=track (*physical appearance* - wide enough for farm vehicles, 
and legal status is irrelevant).


Actual status, designation, etc., to be set as separate (optional) tags.

cheers,

Martin.

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

Re: [Talk-ca] Building Import

[john whelan]

I think at this point in time we need to try to get some sort of agreement
on how to proceed.  My first thought would be to ban the youngsters so
anyone under 65 shouldn't be involved.  That way it would slow the process
down unfortunately it isn't really practical.

I think we need time to digest and review what has been done so far.  I
think it would be sensible for a different mapper to go over the imported
areas using the task manager and verify the buildings against Bing or other
imagery to ensure we haven't introduced an imaginary town etc.

I do think we need to break the import up into more manageable chunks.
Whether these need to be at municipal level or not needs thought.  The case
for is that would allow the data from different sources to be carefully
checked over. The case against is there are a lot of municipalities and in
places like Manitoba there are very few mappers on the ground.

Basically from a population point of view Canada is a collection of around
half a dozen cities and these have a local OSM community.  Montreal,
Ottawa, Vancouver, Toronto for example.  Once you take these out then you
have much smaller numbers.  I'm not certain about Calgary and Edmonton
whether they have a local community or not.

Quebec with its own mailing list is self contained and I think will sort
itself out in time.  Montreal is working together to sort something out.

Terraced houses in Ottawa we just have the outline with a tag of terrace.
This was the way they were mapped even before the City of Ottawa import.
Units may have an individual address node.

At the moment I favour breaking the country up into provinces and for each
province depending on the number of buildings I might split it up again.
So Ontario would be something like Ontario rural and Toronto but I'm not
quite sure of where Toronto begins and ends.

Thoughts and bear in mind that Microsoft has released buildings for Canada
as well.  I haven't noticed an import plan but it would be fairly easy for
someone to bring in some buildings so to retain some sort of control a plan
might well be useful.

Thanks John



On Fri, 15 Mar 2019 at 15:34, Tim Elrick  wrote:

> I think, Montreal's OSMappers would appreciate to discuss the import of
> the buildings there first on the local list. By the way, John, I have never
> said I would be taking the lead for the entirety of Québec (at least, at
> the moment). However, I feel that the import should be discussed on the
> liste OSM de Québec first.
>
> Danny, I disagree with you on the import of building blocks. I find it
> much more tedious to discern them later, then splitting them into single
> buildings first before importing, because, I think, you need to know your
> neighbourhood very well to find unsplit buildings in the OSM database.
> Doing this for a whole town or even city (like Montreal) would take much
> longer than pre-processing.
>
> As for the rest, I have some understanding for the impatience of OSMappers
> about the moratorium on the import - as quite some time has passed and the
> discussion hasn't really moved on nor has the development of the
> countrywide import plan [1] - last change there was beginning of February.
>
> Having looked at the Microsoft data and compared quality to the Open
> Building Database in two places (Montréal, QC and Williams Lake, BC), I
> would suggest to refrain from using it as a source for importing, unless
> you verify them for small areas (but then you can almost draw them by
> hand). In dense areas like downtown Montréal the building footprints are in
> many cases plainly wrong (see my contribution to this list on 2019-03-02,
> 19h57 EST), in more scattered areas and suburban landscapes buildings are
> randomly aligned and quite some buildings are missing (my unverified
> estimate is about 5-10%).
>
> As for the Open Building database, it is important to discern the data by
> the sources as each municipality that contributed data might have used
> different methods and has different mapping standards. Now add the
> disagreement on this list about orthogonalization and building details. I
> think, this suggests breaking up the import plan in smaller batches; for
> the start it can be cloned from the original one, but the pre-processing
> and import process might differ due to how data sources might need to be
> treated as well as how local OSM communities would like to go forward.
>
> What do you reckon?
>
> Tim
>
> [1] https://wiki.openstreetmap.org/wiki/Canada_Building_Import
>
>
> On 2019-03-15 14:01, John Whelan wrote:
> Which I think comes back to defining the local mappers.
>
> There has been discussion on Montreal as well and not all Ontario thinks
> the same way.  Ottawa local mappers for example have different opinions to
> Pierre and Nate on what is acceptable and I'm under the impression that not
> everyone in Toronto agrees with Nate's position.
>
> We seem to be blocking out parts of the country such as Montreal is this a
> reasonable 

Re: [OSM-talk] Proposed mechanical edit - elimination of osmarender:nameDirection - blatant tagging for the renderer

[Martin Koppenhoefer]

Am Fr., 15. März 2019 um 21:27 Uhr schrieb Mateusz Konieczny <
matkoni...@tutanota.com>:

> Because it is especially broken and confusing - and promotes tagging for
> renderer.
>



this is not a case of "tagging for the renderer" as it is usually referred
to (using a tag differently from what it was intended to obtain a certain
result in rendering).
https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer

By the way, there once was a "osmarender"-subtag for curved roads (should
the way be "bezier-treated"), which sounded like a rendering hint, but
actually could be seen as descriptive data (stating whether the way
geometry is approximating a curve or is actually "stepped"). Looks as if it
has been completely "cleaned up".

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

Re: [Talk-GB] Bridleway or track?

[Martin Wynne]

It's entirely reasonable to think "to my mind X means ..." but when 
tagging thing in OSM it makes sense to try and match the approach of 
more people - in OSM, the usage of highway=footway is much wider than 
your definition.


Thanks Andy. But you also wrote recently:

>  just pick whatever seems most appropriate to you. You've been there, 
other people haven't


I've looked again at

 https://wiki.openstreetmap.org/wiki/Tag:highway%3Dfootway

and I'm a bit puzzled which usage of footway is wider than my definition?

It all comes back to my previous question -- is highway= intended to 
*describe* the feature, or indicate its legal status, or record its 
actual usage? That could be three different things.


When I started mapping it was impressed upon me the importance of 
mapping what you see, what is actually on the ground. But as far as 
highways are concerned, and the highway overlay on most renderings, that 
seems not to be the case.


cheers,

Martin.

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

Re: [OSM-talk] Proposed mechanical edit - elimination of osmarender:nameDirection - blatant tagging for the renderer

[Mateusz Konieczny]

Because it is especially broken and confusing - and promotes tagging for 
renderer.

"not hurting anybody in any way" is quite strong claim that I think is false. 

It is not a big problem but every time someone encounters it for the first time
either has one more thing on "confusing things about OSM" or wastes time
on checking what is this thing.

And "create new versions of object" is extremely minor cost.

"The correct way to handle this is to" - I would say that it is a matter of 
opinion what is preferred.

Personally I consider one more entry in history to be vastly less confusing and 
irritating
than a directly visible tag that should not be present.

Mar 15, 2019, 9:13 PM by si...@poole.ch:

>
> Why would we want to create new versions of objects just to  remove a tag 
> that is not hurting anybody in any way? 
>
>
> The correct way to handle this is to add the tag to the list of  
> deprecated tags that should be automatically removed (essentially  iD has 
> a list and JOSM has one too), when and if the objects are  ever edited 
> the tags will then be removed.
>
>
> Simon
>
> Am 15.03.2019 um 20:16 schrieb Mateusz  Konieczny:
>
>> osmarender:nameDirection=* isan old tag that is case of tagging for 
>> the renderer. 
>> Additionally, Osmarender isdefunct anyway.
>>  
>>  I propose to purge this tag from database as useless, confusingand 
>> encouraging
>> tagging for renderer. 
>>
>> This edit would remove about2000 osmarender:nameDirection=* tags 
>> worldwide,
>> with most of them in Germanyand England.
>>
>> osmarender:nameDirection isdescribed on OSM Wiki as 
>>
>> "By default Osmarender willdraw street names left-to-right along 
>> ways. 
>> It uses the longitude(horizontal position) of the start and end 
>> points of the 
>> way to determine thedirection.
>>  
>>  In some cases, for example, very winding roads, theautomatically 
>> chosen
>> name direction is not ideal.In this case the way can be tagged with 
>> osmarender:nameDirection=-1 orosmarender:nameDirection=1 as a 
>> hint to tell Osmarender whichway to draw the name. "
>>
>> Automated edit page:
>> https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/elimination_of_osmarender:nameDirection_-_blatant_tagging_for_the_renderer
>>  
>> 
>>
>> ___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: [Talk-GB] Bridleway or track?

[Andy Townsend]

On 15/03/2019 18:24, Dave F via Talk-GB wrote:


Are there any data users who use 'highway=footway;foot=yes' to 
distinguish from other footways?



Sort-of - depending on other tags 
https://map.atownsend.org.uk/maps/map/map.html can display things 
differently based on that, but it'd be a pretty niche set of 
circumstances.  See 
https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L614 
.


Personally I tend to add "foot=yes" when that is the correct tag rather 
than rely on "assumed defaults" or the implications of 
"designation=public_footpath" because it's more explicit.  It's always a 
tradeoff between how many tags to add and how many is too many - for 
example I wouldn't add "oneway=no" to the majority of roads that 
aren't,  but it would make sense to mark "the only road across town that 
isn't one-way" like that.


Best Regards,

Andy



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

Re: [OSM-talk] Proposed mechanical edit - elimination of osmarender:nameDirection - blatant tagging for the renderer

[Simon Poole]

Why would we want to create new versions of objects just to remove a tag
that is not hurting anybody in any way?

The correct way to handle this is to add the tag to the list of
deprecated tags that should be automatically removed (essentially iD has
a list and JOSM has one too), when and if the objects are ever edited
the tags will then be removed.

Simon

Am 15.03.2019 um 20:16 schrieb Mateusz Konieczny:
> osmarender:nameDirection=* is an old tag that is case of tagging for
> the renderer.
> Additionally, Osmarender is defunct anyway.
>
> I propose to purge this tag from database as useless, confusing and
> encouraging
> tagging for renderer.
>
> This edit would remove about 2000 osmarender:nameDirection=* tags
> worldwide,
> with most of them in Germany and England.
>
> osmarender:nameDirection is described on OSM Wiki as
>
> "By default Osmarender will draw street names left-to-right along ways.
> It uses the longitude (horizontal position) of the start and end
> points of the
> way to determine the direction.
>
> In some cases, for example, very winding roads, the automatically chosen
> name direction is not ideal. In this case the way can be tagged with
> osmarender:nameDirection=-1 or osmarender:nameDirection=1 as a
> hint to tell Osmarender which way to draw the name. "
>
> Automated edit page:
> https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/elimination_of_osmarender:nameDirection_-_blatant_tagging_for_the_renderer
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [Talk-GB] Bridleway or track?

[Andy Townsend]

On 15/03/2019 19:21, Martin Wynne wrote:



To my mind:

highway=footway means a narrow smooth physical object capable of being 
walked along in safety.


It's entirely reasonable to think "to my mind X means ..." but when 
tagging thing in OSM it makes sense to try and match the approach of 
more people - in OSM, the usage of highway=footway is much wider than 
your definition.



But I'm sure someone will disagree, and the wiki is no help in 
deciding the matter. :)


Indeed - rather than what the last person to edit the wiki wrote, I'd 
try and follow global and local tagging norms.  This doesn't mean that 
there aren't excellent wiki pages that people have taken great care of - 
just that there are some that don't live up to that (and some that 
actually contradict each other).


Best Regards,

Andy




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

Re: [Talk-ca] Building Import

[Tim Elrick]

I think, Montreal's OSMappers would appreciate to discuss the import of 
the buildings there first on the local list. By the way, John, I have 
never said I would be taking the lead for the entirety of Québec (at 
least, at the moment). However, I feel that the import should be 
discussed on the liste OSM de Québec first.


Danny, I disagree with you on the import of building blocks. I find it 
much more tedious to discern them later, then splitting them into single 
buildings first before importing, because, I think, you need to know 
your neighbourhood very well to find unsplit buildings in the OSM 
database. Doing this for a whole town or even city (like Montreal) would 
take much longer than pre-processing.


As for the rest, I have some understanding for the impatience of 
OSMappers about the moratorium on the import - as quite some time has 
passed and the discussion hasn't really moved on nor has the development 
of the countrywide import plan [1] - last change there was beginning of 
February.


Having looked at the Microsoft data and compared quality to the Open 
Building Database in two places (Montréal, QC and Williams Lake, BC), I 
would suggest to refrain from using it as a source for importing, unless 
you verify them for small areas (but then you can almost draw them by 
hand). In dense areas like downtown Montréal the building footprints are 
in many cases plainly wrong (see my contribution to this list on 
2019-03-02, 19h57 EST), in more scattered areas and suburban landscapes 
buildings are randomly aligned and quite some buildings are missing (my 
unverified estimate is about 5-10%).


As for the Open Building database, it is important to discern the data 
by the sources as each municipality that contributed data might have 
used different methods and has different mapping standards. Now add the 
disagreement on this list about orthogonalization and building details. 
I think, this suggests breaking up the import plan in smaller batches; 
for the start it can be cloned from the original one, but the 
pre-processing and import process might differ due to how data sources 
might need to be treated as well as how local OSM communities would like 
to go forward.


What do you reckon?

Tim

[1] https://wiki.openstreetmap.org/wiki/Canada_Building_Import


On 2019-03-15 14:01, John Whelan wrote:
Which I think comes back to defining the local mappers.

There has been discussion on Montreal as well and not all Ontario thinks 
the same way.  Ottawa local mappers for example have different opinions 
to Pierre and Nate on what is acceptable and I'm under the impression 
that not everyone in Toronto agrees with Nate's position.


We seem to be blocking out parts of the country such as Montreal is this 
a reasonable approach?


Can we find someway to loosely define local groups and their areas of 
responsibility and how to contact them?


For example one small Ontario city has to my knowledge one OpenStreetMap 
mapper who maps very occasionally.  My understanding is they would be 
quite happy to see an import happen but many of the buildings have 
already been mapped although not to the accuracy that the Stats Can data 
offers. How do you deal with these smaller cities and townships?


Thanks

Cheerio John

Paul Norman via Talk-ca wrote on 2019-03-15 1:45 PM:

On 2019-03-15 9:07 a.m., Andrew Lester wrote:

I disagree. Silence won't solve anything.

I'm speaking here as a local BC mapper, and I strongly disa gree with 
these recent imports.


I'm also a BC mapper, and have only seen the consultation happen over 
Ontario, not BC.



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


--
Sent from Postbox 



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


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

Re: [OSM-talk-fr] Calcul d'itinéraire avec OSRM - questionnement calcul

[Violaine_Do]

Merci pour les retours! J'ai fais un test sur un itinéraire plutôt 
rectiligne c'est pour ça que je comprends pas le calcul. Après je 
comprends les différences entre usage et limites max..


@Rodrigo, super intéressant et inspirant ton article!

Bonne soirée


On 15/03/2019 04:10, Rpnpif wrote:

Le 14 mars 2019, Violaine_Do a écrit :


Bonjour tout le monde,

Je me demandais comment améliorer le calcul d'itinéraire, avec OSRM (sur
osm.org) en fonction de conditions locales (cf profil voiture utilisé
sur OSM.org 1)

Pour le moment primary, secondary et tertiary ne montent par défaut pas
a plus de 65km/h, les exceptions rurales sont souvent au dessus.. (cf
wiki speed limits : 2, par exemple pour les routes rurales en france on
a comme tag maxspeed=80 + source:maxspeed=FR:rural) Donc avec maxspeed
on dépasse la vitesse par défaut du type de route tertiary, secondary,
primary. Mais pour avoir fait un petit test, je comprends pas le calcul,
par exemple avec un tronçon en particulier (3) : je ne trouve pas la
vitesse attendue (j'aimerais que le calcul prenne en compte la vitesse
rurale c'est à dire 80km/h plutôt que la vitesse du type de route
secondary qui est à 55km/h, information qui est présente sur ce
tronçon). Est-ce que c'est parce que primary/secondary/tertiary sont
prioritaires/contraignent le reste? (en gros faudrait il changer les
vitesses par defaut primary/secondary/tertiary pour permettre
l'utilisation des maxspeed?). J'espère que je suis assez compréhensible...

Sur une route à 80 km/h, on ne roule pas à 80 km/h en moyenne sauf si
on dépasse la vitesse légale, à cause des décélérations, etc. C'est
peut-être pourquoi la vitesse est calculée en dessous, peut-être 5 à 20% en 
dessous.


--
Violaine_Do


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

Re: [talk-cz] Relace s jedním členem

[Milan Cerny]

Vím, že to dělá problémy programům s lokálním renderováním map Mapforge (Locus, 
Cruiser...) , kde se uzavřené linie obsahující tag plochy i linie zobrazují 
chybně nebo vůbec.
Nejčastěji je to vidět u fotovoltaických elektráren. 


__
> Od: "majka" 
> Komu: "OpenStreetMap Czech Republic" 
> Datum: 14.03.2019 20:42
> Předmět: Re: [talk-cz] Relace s jedním členem
>
>V podstatě s tebou souhlasím, právě proto se mi ty mutipolygony, co jsou
>tam jednoznačně navíc, silně příčí :)
>
>Tady to je (2014, dané jako jedna z možností):
>https://help.openstreetmap.org/questions/38273/how-to-map-barriers-like-fences-on-landuse-borders
>
>Našla jsem to i někde jinde, ale už si nevybavím kde.
>
>On Thu, 14 Mar 2019 at 20:20, Marián Kyral  wrote:
>
>>
>> -- Původní e-mail --
>> Od: majka 
>> Komu: OpenStreetMap Czech Republic 
>> Datum: 14. 3. 2019 20:09:29
>> Předmět: Re: [talk-cz] Relace s jedním členem
>>
>>
>> Ne všechno bude zbytečné - např. oplocená zahrada se někde doporučovala
>> jako multipolygon, s tím že plot bude ta cesta a polygon ta zahrada.
>>
>>
>> Tak o tomhle jsem v životě neslyšel. Buď má zahrada a oplocení společnou
>> cestu, pak dám oba tagy na tu cestu, nebo se liší a to pak udělám dvě
>> cesty. Tahat do toho multipolygony mi přijde moc komplikované. Časem by to
>> mohlo skončit tím že všechno bude relace a při úpravách se z toho po…m
>>
>> Marián
>> ___
>> talk-cz mailing list
>> talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
>>
>
>
>--
>
>___
>talk-cz mailing list
>talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz
>https://openstreetmap.cz/talkcz
>
>

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

Re: [Talk-GB] Bridleway or track?

[Martin Wynne]

Are there any data users who use 'highway=footway;foot=yes' to 
distinguish from other footways?


I also find much of the wiki unclear.

To my mind:

highway=footway means a narrow smooth physical object capable of being 
walked along in safety.


If you can't do that, it is not a footway. So for example, where there 
is a stile in a hedge set back from a road, I would terminate the 
footway at the stile, and link from there to the centre of the road with 
simply highway=yes for routing purposes.


foot=yes means that the general public are allowed to use it at all 
times for any reason. As opposed to private, permissive, destination 
only, etc.


foot=designated + designation=public_footpath means that the said path 
is also shown on the highway authority's definitive map as a legal right 
of way. Many urban footpaths are not so shown.


But I'm sure someone will disagree, and the wiki is no help in deciding 
the matter. :)


cheers,

Martin.



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

Re: [Talk-ca] Building Import

[Pierre Béland via Talk-ca]

John, 

les contributeurs de Ottawa, vous semblez en général d'accord pour poursuivre 
les imports et avez la capacité technique de faire des imports rapides, ce que 
vous avez démontré.  Il ne manque qu'un petit pas à franchir et discuter de la 
qualité des données et accepter de tenir compte des communautés en général.
Essaies tu de dire que les 6 contributeurs qui ont fait des imports se sont 
limités à des territoires locaux, voire leur province et ont discuté avec les 
communautés locales sur la méthodologie satisfaisante pour corriger les données 
avant l'import ?   Pour le Québec, je peux te dire que non.

Je constate plutot un refus de discuter et une volonté de poursuivre malgré les 
opinions divergentes. Et la qualité ?  J'ai clairement démontré il me semble 
que les tracés imprécis étaient clairement visibles.  Et si je comprends bien, 
nous avons maintenant un million de nouveaux bâtiments que l'on pourrait 
«blanchir» si n'importe qui met un tampon approuv dessus.  Je dois dire que 
l'argument est difficile à avaler.
 
Pierre 
 

Le vendredi 15 mars 2019 14 h 02 min 23 s HAE, John Whelan 
 a écrit :  
 
 Which I think comes back to defining the local mappers.

There has been discussion on Montreal as well and not all Ontario thinks the 
same way.  Ottawa local mappers for example have different opinions to Pierre 
and Nate on what is acceptable and I'm under the impression that not everyone 
in Toronto agrees with Nate's position.

We seem to be blocking out parts of the country such as Montreal is this a 
reasonable approach?

Can we find someway to loosely define local groups and their areas of 
responsibility and how to contact them?

For example one small Ontario city has to my knowledge one OpenStreetMap mapper 
who maps very occasionally.  My understanding is they would be quite happy to 
see an import happen but many of the buildings have already been mapped 
although not to the accuracy that the Stats Can data offers.  How do you deal 
with these smaller cities and townships?

Thanks

Cheerio John  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[OSM-talk] Proposed mechanical edit - elimination of osmarender:nameDirection - blatant tagging for the renderer

[Mateusz Konieczny]

osmarender:nameDirection=* is an old tag that is case of tagging for the 
renderer. 
Additionally, Osmarender is defunct anyway.

I propose to purge this tag from database as useless, confusing and encouraging 
tagging for renderer. 

This edit would remove about 2000 osmarender:nameDirection=* tags worldwide,
with most of them in Germany and England.

osmarender:nameDirection is described on OSM Wiki as 

"By default Osmarender will draw street names left-to-right along ways. 
It uses the longitude (horizontal position) of the start and end points of the 
way to determine the direction.

In some cases, for example, very winding roads, the automatically chosen name 
direction is not ideal. In this case the way can be tagged with 
osmarender:nameDirection=-1 or osmarender:nameDirection=1 as a 
hint to tell Osmarender which way to draw the name. "

Automated edit page:
https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/elimination_of_osmarender:nameDirection_-_blatant_tagging_for_the_renderer
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] Bridleway or track?

[Nick Whitelegg]

I would urge the use of 'foot=yes' or 'foot=permissive' for paths which are 
_not_ rights of way but _do_ have public access (implicitly or explicitly) 
rather than simply 'highway=footway' or 'highway=path'. There needs to be a way 
to distinguish between non-rights-of-way which definitely have public access 
and those which may not - so that, for example, routing software will not try 
and route you along some path which is private but is just missing a 'PRIVATE' 
sign currently.


For instance a path between roads in towns which is not a right of way I'd use 
'foot=yes', while one in the countryside marked as permissive I'd use 
'foot=permissive'.



Nick


From: Dave F via Talk-GB 
Sent: 15 March 2019 18:24:40
To: talk-gb@openstreetmap.org
Subject: Re: [Talk-GB] Bridleway or track?

>From the footnote of that table:
"The United Kingdom Tagging 
Guidelines
 state that highway=path, when used it the UK, implies "a generic narrow path 
that is used in conjunction with access tags". This makes the default "yes" 
assumption dubious."

What does foot=yes mean?
https://wiki.openstreetmap.org/wiki/Path_examples
Some wiki pages say it's 'legal right' another says "A urban path without any 
legal status suitable for walking."

This is a reason why I take much of the wiki with a pinch of salt. 'foot=yes' 
should be used in combination with the access tag (usually when it's  set to 
'no' or 'private') not as a stand alone sub tag (ie highway=footway;foot=yes).

Are there any data users who use 'highway=footway;foot=yes' to distinguish from 
other footways?

DaveF


On 15/03/2019 11:05, David Woolley wrote:
On 15/03/2019 01:24, Dave F via Talk-GB wrote:
AFAIA, neither tag had any impied permissions or condition attributes.

They do, and they are country specific.





___
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] Quartiers à Paris

[althio]

marc marc :

De: "althio"
 > si quelqu'un veut supprimer le quartier administratif

c'est une caricature surement volontaire pour provoquer
les partisans de l'inverse mais cela n'a aucun sens.
[…]
c'est déjà parfois difficile de se comprendre sans 2ieme ou 3ieme degré,
alors évitons les :)


Vincent de Château-Thierry :


Donc le fait qu'une donnée n'aie "aucune existence de terrain" et/ou se
"retrouve en open data" serait une raison suffisante pour la saccager dans
OSM : renommage inconsidéré, suppression... Avec une logique pareille, […]


Effectivement, mea culpa, je retire ce que j'ai écrit.
J'aurais pu entourer ces passages avec des balises "ironie", "provocation"
ou "troll", ajouter des smileys… et au final j'aurais du m'abstenir tout
simplement.
En outre, la vérité est que je ne me moque pas tout à fait de ces données
de limites administratives.

Là où je suis rassuré, c'est qu'il y a du monde pour les défendre :)



D'un autre côté, des données ont été effacées pour de vrai, dans une autre
gamme de provocation, ont échauffé les esprits et font dépenser beaucoup
d'énergie dans ces discussions.
Je vais profiter du week-end pour souffler un bon coup ;)


En élargissant, je pense que tous les découpages ont leur place dans OSM :
administratifs, religieux, militaires, académiques et j'en passe, dès lors
qu'on dispose d'une source précise et compatible pour leur délimitation.


Un avis sur les quartiers qui n'ont pas de délimitation, sans source
précise ? C'est un des gros sujets de ce fil, et on demande l'avis de tout
le monde.

Bonne soirée et bon week-end à tout le monde.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Bridleway or track?

[Dave F via Talk-GB]

From the footnote of that table:
"The United Kingdom Tagging Guidelines 
 
state that highway=path, when used it the UK, implies "a generic narrow 
path that is used in conjunction with access tags". This makes the 
default "yes" assumption dubious."


What does foot=yes mean?
https://wiki.openstreetmap.org/wiki/Path_examples
Some wiki pages say it's 'legal right' another says "A urban path 
without any legal status suitable for walking."


This is a reason why I take much of the wiki with a pinch of salt. 
'foot=yes' should be used in combination with the access tag (usually 
when it's  set to 'no' or 'private') not as a stand alone sub tag (ie 
highway=footway;foot=yes).


Are there any data users who use 'highway=footway;foot=yes' to 
distinguish from other footways?


DaveF


On 15/03/2019 11:05, David Woolley wrote:

On 15/03/2019 01:24, Dave F via Talk-GB wrote:

AFAIA, neither tag had any impied permissions or condition attributes.


They do, and they are country specific.

 





___
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-ca] Building Import

[John Whelan]

Which I think comes back to defining the local mappers.

There has been discussion on Montreal as well and not all Ontario thinks 
the same way.  Ottawa local mappers for example have different opinions 
to Pierre and Nate on what is acceptable and I'm under the impression 
that not everyone in Toronto agrees with Nate's position.


We seem to be blocking out parts of the country such as Montreal is this 
a reasonable approach?


Can we find someway to loosely define local groups and their areas of 
responsibility and how to contact them?


For example one small Ontario city has to my knowledge one OpenStreetMap 
mapper who maps very occasionally.  My understanding is they would be 
quite happy to see an import happen but many of the buildings have 
already been mapped although not to the accuracy that the Stats Can data 
offers.  How do you deal with these smaller cities and townships?


Thanks

Cheerio John

Paul Norman via Talk-ca wrote on 2019-03-15 1:45 PM:

On 2019-03-15 9:07 a.m., Andrew Lester wrote:

I disagree. Silence won't solve anything.

I'm speaking here as a local BC mapper, and I strongly disagree with 
these recent imports.


I'm also a BC mapper, and have only seen the consultation happen over 
Ontario, not BC.



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


--
Sent from Postbox 

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

Re: [OSM-talk-fr] GogoCarto

[Cédric Frayssinet]

Le 15/03/2019 à 09:03, allegre.guilla...@free.fr a écrit :
> Le 14/03/2019 21:28, Cédric Frayssinet a écrit :
>> Bonsoir à tous,
>>
>> Le projet ne semble pas être passé par cette liste. Voici GogoCarto,
>> un chouette projet, très joli, un peu à la uMap, qui permet de faire
>> de jolies cartes : https://gogocarto.fr/projects
>
> Pour les gens qui connaissent déjà uMap, pourrais-tu donner succintement
> les principales différences ?

Je me suis posé la même question. Il y en a 1 évidente, c'est vraiment
plus joli :)

Vincent B. m'a répondu cela sur une autre liste :

/je n'ai pas encore assez exploré gogocarto pour faire une revue
complète. Cependant parmi les différences que je vois :/

//

  * /esthétique indéniable/
  * /un système de vote pour valider des ajouts de points/
  * /un sous domaine généré et non une adresse/

//

/Ce que je ne sais pas c'est :/

//

  * /quel volume de carte cela peut gérer (300 000 cartes umap sur les
serveurs osm-fr pour la seule instance umap.openstreetmap.fr)//
/
  * /les diverses interopérabilités (mais Sébastian, le dev, est très
favorable et attentif à cela)/


Cédric

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

Re: [OSM-talk-fr] schéma pour renseigner les découpages [était : Quartiers à Paris]

[Léo El Amri via Talk-fr]

On 15/03/2019 18:21, marc marc wrote:
> Le 15.03.19 à 17:34, Léo El Amri via Talk-fr a écrit :
>> Les aires sont définies <...> avec area=yes.
> 
> pas nécessairement.
> De nombreux objet définissent automatiquement une aire implicitement
> natural=wood landuse=* place=* building=* les relations polygone, etc
> Pas besoin par exemple de mettre building=yes area=yes parce qu'il 
> n'existe pas de building=yes area=no
> 
> area=yes s'ajoute uniquement sur les objets pouvant parfois décrire
> une ligne, parfois une aire :
> ex highway=footway, si le way est fermé, c'est un chemin qui fait une 
> boucle ou c'est une aire ? on considère par défaut que c'est une ligne 
> et on ajoute area=yes pour préciser quand c'est une aire.

Tu semblais dire que c'était un tag qui définissait si un objet était
une aire ou non. Je donnais l'exemple explicite de area=yes en précisant
que seuls les ways pouvaient être des area. ;)

On est sur la même longueur d'onde en fait.

>> catégoriser la relation, area ou node, par exemple:
>> "type_decoupage=admin" pour les infos tirées du cadastre
> 
> la façon actuelle de faire est :
> relation type=boundary bounary=administrative
> et source=cadastre sur le changeset
> 
>> ou "type_decoupage=usuel" pour les découpages "populaires"
>> (Les fameux quartiers de Paris).
> 
> place=* et source=local_knownledge ou survey sur le changeset selon que 
> c'est une connaissance ou vu sur le terrain

On pourrait donc étendre un peu les valeurs de `source`, et peut-être
rajouter un tag pour certaines précisions. Par exemple,
source=local_knowledge englobe les types "populaire" (Que j'ai décris
plus tôt) et "académique" (Décris superficiellement par Vincent de
Château-Thierry).

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

Re: [OSM-talk-fr] Quartiers à Paris

[osm . sanspourriel]

Souvent dans ce cas on peut utiliser un landuse=residential et le nommer.

Le 15/03/2019 à 17:34, Léo El Amri via Talk-fr - 
talk-fr@openstreetmap.org a écrit :

On 15/03/2019 16:59, marc marc wrote:

Le 15.03.19 à 16:29, Léo El Amri via Talk-fr a écrit :

catégoriser les découpages

je pense que la majorité existent déjà.

Par exemple pour le quartier de Paris,
le populaire (celui avec un place=*) ayant une limite
que personne ne semble contester, il peux facilement
être tagé comme une aire : c'est la seule façon de transformer
l'étendue bleue de l'image précédente en donnée osm.

sinon on arrive à un résultat incohérent : on dit que le quartier
populaire mérite d'être ajouté dans osm car différent du découpage
administratif du même nom, mais l'ajout dans osm ne montre pas cette
différence et mettre une note sur les 2 objets ne permet pas plus
"d'utiliser" cette différence.

Les aires sont définies par des ways fermés et tagués avec area=yes.

Techniquement, dans mon exemple, je souhaitais taguer les relations, ou
si il n'y en a pas, les area ou les nodes. L'idée est d'avoir un tag qui
permette de catégoriser la relation, area ou node, par exemple:
"type_decoupage=admin" pour les infos tirées du cadastre, la maire ou
que sais-je ou "type_decoupage=usuel" pour les découpages "populaires"
(Les fameux quartiers de Paris).

___
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: [Talk-ca] Building Import

[Paul Norman via Talk-ca]

On 2019-03-15 9:07 a.m., Andrew Lester wrote:

I disagree. Silence won't solve anything.

I'm speaking here as a local BC mapper, and I strongly disagree with 
these recent imports.


I'm also a BC mapper, and have only seen the consultation happen over 
Ontario, not BC.



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

Re: [OSM-talk-fr] Tuiles cadatsre sans réponse sur JOSM

[osm . sanspourriel]

Tu le lances comment ?

Si c'est via le .jnlp, tu peux ajouter le paramètre dedans.

Si c'est via le jar, tu ajoutes l'argument indiqué en lançant la 
commande (typiquement dans un .bat sur PC, dans un .sh sur Linux).


Si c'est par un exécutable, tu te ramènes au cas précédent ;-). Il y a 
peut-être moyen de mettre l'argument si tu crées un raccourci.


Le 15/03/2019 à 17:37, Jérôme Seigneuret - jerome.seigneu...@gmail.com a 
écrit :

tu es sous quoi? windows linux mac?


Le ven. 15 mars 2019 à 15:20, Jozeph via Talk-fr 
mailto:talk-fr@openstreetmap.org>> a écrit :


Bonjour,

Oui je rencontre ce problème depuis hier avec le message :

"Erreur lors du chargement des tuiles :
javax.net.ssl.SSLProtocolException handshake alert: unrecognized_name"

Je ne sais pas introduire le paramètre supplémentaire dans le lancement de 
JOSM comme indiqué par Denis.

Que me conseillez-vous ?

Avec mes remerciements.

Joseph

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



--
Cordialement,
Jérôme Seigneuret

___
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: [Talk-ca] Saints in street names in Ontario

[Nate Wessel]

Interesting!

I didn't mean to imply that etymology should be decisive, but that 
linking the name to the history of some beatified person would help 
explain the origin of the 'St'... In this case, seemingly supporting the 
abbreviation, but also referencing an actual 'saint' or two at the same 
time.


I like Danny's suggestion of the pronunciation tag. That seems like the 
most elegant solution if anyone knows IPA. I've always wanted to learn 
it actually but haven't yet had a good enough reason.


Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 3/15/19 1:18 PM, Jarek Piórkowski wrote:

On Fri, 15 Mar 2019 at 13:02, Nate Wessel  wrote:

Don't forget about the various alternative naming tags like alt_name=*, 
short_name=*, loc_name=*, and also name:etymology=* to make things absolutely 
clear.

Having either spelling in one of these alternatives as appropriate would likely 
satisfy any dissenters and make both the full and abbreviated name searchable.

Certainly, but my message is to suggest that "St. Clair Avenue West"
_is_ the full name. We could set up an "expanded name" tag I suppose?

Etymology wise, Wikipedia, citing (as far as I can tell) local
historians, suggests that St. Clair Avenue is named after Augustine
St. Clare, a character in Uncle Tom's Cabin, and the book spells the
last name "St. Clare", never expanded to "Saint".

In any case, suggesting etymology as being decisive for names seems to
me problematic in many ways, especially in Canada where we've
adopted/mangled many names and phrases from other languages.

Thanks,
--Jarek
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import

[John Whelan]

I think there are two issues here the first is I accept having a large 
number of anything by one mapper has the potential for a systematic error.


If the import is verified by a second mapper independently I assume this 
would be acceptable?


The second is more to do with discussion within the community and is I 
feel more complex.


Cheerio John

Frederik Ramm wrote on 2019-03-15 12:06 PM:

Hi,

On 15.03.19 16:23, Danny McDonald wrote:

I think many people on this list fundamentally misunderstand the way OSM
operates.  Most OSM contributions are made by individuals who see a
gap/mistake in the data and fix it.

True!


It is not a "community process"
where contributions are made by a group of "local mappers" (although
this sometimes happens).

True!

As long as we're talking normal, everyday, "manual" mapping. Like, 100
edits a day, or maybe 1000 edits on a good day.

For things that go beyond a little mapping by the individual, we tend to
have processes, e.g. for imports, for automated edits, for organised edits.

The general idea behind the discuss-these-things-first rules is not that
one mapper is better than another, but quite the opposite: One mapper
alone can actually make stupid mistakes or suffer from bad judgement,
something that the larger community can help against.

Bye
Frederik



--
Sent from Postbox 

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

Re: [Talk-it] R: R: Tag place

[Martin Koppenhoefer]

sent from a phone

> On 24. Feb 2019, at 18:34, Andrea Musuruane  wrote:
> 
> 
> Barozzo da hamlet a neighbourhood
> https://www.openstreetmap.org/node/5341787782
> 
> Alberto da hamlet a neighbourhood
> https://www.openstreetmap.org/node/5669345431
> 
> Trabaldo da hamlet a neighbourhood
> https://www.openstreetmap.org/node/5669345439



mi sembra strano che una fusione di comuni possa avere subito effetto sulle 
identità dei place, da hamlet a neighborhood, ma ammetto di non conoscere i 
posti.

Ciao, Martin ___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-ca] Saints in street names in Ontario

[john whelan]

I'm of the opinion that what the city says goes.

We used that in Ottawa with things such as rue Slater rather than Rue
Slater which I understand is more normal in Quebec.

Cheerio John

On Fri, Mar 15, 2019, 1:19 PM Jarek Piórkowski,  wrote:

> On Fri, 15 Mar 2019 at 13:02, Nate Wessel  wrote:
> > Don't forget about the various alternative naming tags like alt_name=*,
> short_name=*, loc_name=*, and also name:etymology=* to make things
> absolutely clear.
> >
> > Having either spelling in one of these alternatives as appropriate would
> likely satisfy any dissenters and make both the full and abbreviated name
> searchable.
>
> Certainly, but my message is to suggest that "St. Clair Avenue West"
> _is_ the full name. We could set up an "expanded name" tag I suppose?
>
> Etymology wise, Wikipedia, citing (as far as I can tell) local
> historians, suggests that St. Clair Avenue is named after Augustine
> St. Clare, a character in Uncle Tom's Cabin, and the book spells the
> last name "St. Clare", never expanded to "Saint".
>
> In any case, suggesting etymology as being decisive for names seems to
> me problematic in many ways, especially in Canada where we've
> adopted/mangled many names and phrases from other languages.
>
> Thanks,
> --Jarek
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-fr] schéma pour renseigner les découpages [était : Quartiers à Paris]

[marc marc]

Le 15.03.19 à 17:34, Léo El Amri via Talk-fr a écrit :
> Les aires sont définies <...> avec area=yes.

pas nécessairement.
De nombreux objet définissent automatiquement une aire implicitement
natural=wood landuse=* place=* building=* les relations polygone, etc
Pas besoin par exemple de mettre building=yes area=yes parce qu'il 
n'existe pas de building=yes area=no

area=yes s'ajoute uniquement sur les objets pouvant parfois décrire
une ligne, parfois une aire :
ex highway=footway, si le way est fermé, c'est un chemin qui fait une 
boucle ou c'est une aire ? on considère par défaut que c'est une ligne 
et on ajoute area=yes pour préciser quand c'est une aire.

> catégoriser la relation, area ou node, par exemple:
> "type_decoupage=admin" pour les infos tirées du cadastre

la façon actuelle de faire est :
relation type=boundary bounary=administrative
et source=cadastre sur le changeset

> ou "type_decoupage=usuel" pour les découpages "populaires"
> (Les fameux quartiers de Paris).

place=* et source=local_knownledge ou survey sur le changeset selon que 
c'est une connaissance ou vu sur le terrain
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Your thoughts on osm.org

[Martijn van Exel]

Hi all, thanks for sharing. Some recurring / interesting topics I picked up:

* More attention to community, local groups, mapping together, the ‘people’ 
aspect of OSM
* Still have a map but smaller
* More information directly on or accessible from main page, for example
* How-to / learn to map
* What is OSM (video?)
* Showcasing things that are made / done with OSM data

Martijn

> On Mar 12, 2019, at 10:58 AM, Martijn van Exel  wrote:
> 
> Hi all,
> 
> Here’s something I ask myself from time to time and would like to hear other 
> people’s thoughts about.
> 
> Imagine the openstreetmap.org home page, but without the map.
> What would the home page be about instead? What would be on it?
> 
> Thanks for sharing,
> Martijn
> ___
> 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] Places PMR ?

[PanierAvide]

Bonjour,

Pour info :

3. amenity=parking_space + disabled=* -> 524
4. amenity=parking_space + access:disabled=*  -> 1627

Donc effectivement les méthodes 1. ou 2. sont majoritaires, le 1 étant 
raccord avec la logique des amenity=parking, et le 2 avec la logique 
sémantique. Et d'accord pour que le wheelchair reste centré sur 
l'accessibilité physique de la place. Malgré que le 4 soit techniquement 
recommandé par le wiki, l'usage ne suit pas.


J'ai mis à jour la page wiki [1] pour indiquer l'état actuel des tags, 
mais ce serait bien qu'on fasse un peu de ménage sur les tags 
minoritaires pour que ce soit un peu moins le bazar :-) On part sur 
capacity:disabled=* ?


Cordialement,

Adrien.

[1] https://wiki.openstreetmap.org/wiki/FR:Handicaps/R%C3%A9f%C3%A9rentiel


Le 15/03/2019 à 17:56, Vincent Bergeot a écrit :

Bonjour,

bon du coup je boucle et je ne sais pas trop comment déboucler :)

Je parle ici seulement du tag amenity=parking_space pour 1 seule place 
de parking réservée pour des personnes à mobilité réduite (titulaire 
d'un macaron)


Plusieurs schémas (je mets de coté wheelchair qui va qualifier 
l'effectivité de l'accessibilité en fauteuil) et si on regarde les 
combinaisons : 
https://taginfo.openstreetmap.org/tags/amenity=parking_space#combinations


 1. amenity=parking_space + capacity:disabled=*-> un peu plus de 10
000 occurrence
 2. amenity=parking_space + parking_space=disabled -> un peu moins de
10 000 occurences
 3. amenity=parking_space + disabled=yes/designated -> ?
 4. amenity=parking_space + access:disabled=designated  -> ?
 5. amenity=parking_space + wheelchair -> 19500 avec 16000 yes

5 -> c'est l'effectivité de l'accessibilité en fauteuil donc à part.

3 et 4 pas beaucoup d'occurrences, du moins sur la page

1 et 2 assez proche

1 -> le tag capacity:disabled=* est plus adapté à un ensemble de 
places dont une partie capacity:disabled=*


2 -> "pas cohérent avec parking=surface/sous-terrain" mais une place 
de parking en souterrain ou silo fera partie d'un amenity=parking qui 
lui sera taggué parking=surface/sous-terrain -> je ne suis pas sur que 
les valeurs des clés parking et parking_space aient besoin d'être 
cohérentes.


Il est fait référence dans la page de proposition 
(https://wiki.openstreetmap.org/wiki/Proposed_features/parking#Parking_space) 
à la fois au place de parking pour le carpool, disabled, ...


Bon j'arrête, je ne suis pas sur d'avoir fini de boucler !!!

à vous lire !




Le 11/03/2019 à 11:30, PanierAvide a écrit :


Bonjour,

Le tag capacity=* sur amenity=parking_space est utilisable si 
l'emprise comporte plusieurs places. Mais le wiki précise aussi que 
les tags capacity:*=* ne sont pas utilisables sur les parking_space, 
qu'il faut plutôt utiliser access:*=*...


Donc à priori ce serait amenity=parking_space + access=no + 
access:disabled=designated + wheelchair=* (+ capacity=* si plusieurs 
places collées). Ça en fait des tags pour indiquer une place PMR ! 
Utiliser parking_space=disabled simplifierait la chose, ou pas si on 
se retrouve à devoir le combiner avec les "anciens" tags.


Cordialement,

Adrien P.
Le 11/03/2019 à 10:32, Vincent Bergeot a écrit :

Bonjour,
je reprends ce fil car la question me hante (au moins !!!)/

Dans le cas d'une *place individuelle de parking de type 
stationnement réservé pour les personnes handicapées ou à mobilité 
réduite* :


  * amenity=parking_space OK -> cela décrit 1 place
  * capacity:disabled=1 je ne comprends pas car on vient déjà de
dire que c'est 1 avec parking_space (puisque que cela décrit
justement une place), donc j'ai tendance à penser que c'est par
défaut capacity=1 et que dans le cas de amenity=parking_space
cela n'a pas de "sens" de définir des capacity
  * parking_space=disabled (effectivement peu renseigné sur le wiki
et utilisé surtout en europe),
  * wheelchair venant renseigner alors l'effectivité de
l'accessibilité en fauteuil

Ce que je ne vois pas c'est pourquoi parking_space=* ne serait pas 
plus utilisé (pour disabled mais sans doute aussi pour les places 
familles devant les supermarchés, les places réservées, carpool, 
comme d'ailleurs l'illustre la photo de la page wiki :

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space)

au plaisir de vous lire




Le 19/03/2018 à 11:06, PanierAvide a écrit :


Bonjour Marc et Jérôme,

Merci pour vos deux réponses, ça montre bien une divergence des 
pratiques :-) Effectivement l'ambiguïté de la représentation porte 
sur les places individuelles, le cas du décompte sur un parking 
global est pour le coup explicite avec capacity:disabled=*.


Malgré la confusion, de ce que je comprends, il y a quand même 
consensus sur les points suivants :


- wheelchair=yes indique l'accessibilité réelle sur le terrain de 
la place

- Il vaudrait mieux se baser des tags orientés access=*

Après je vois qu'il y a pléthore de valeurs possibles si on part 
sur la logique access. Pourquoi un combo amenity=parking_space 

Re: [Talk-ca] Saints in street names in Ontario

[Jarek Piórkowski]

On Fri, 15 Mar 2019 at 13:02, Nate Wessel  wrote:
> Don't forget about the various alternative naming tags like alt_name=*, 
> short_name=*, loc_name=*, and also name:etymology=* to make things absolutely 
> clear.
>
> Having either spelling in one of these alternatives as appropriate would 
> likely satisfy any dissenters and make both the full and abbreviated name 
> searchable.

Certainly, but my message is to suggest that "St. Clair Avenue West"
_is_ the full name. We could set up an "expanded name" tag I suppose?

Etymology wise, Wikipedia, citing (as far as I can tell) local
historians, suggests that St. Clair Avenue is named after Augustine
St. Clare, a character in Uncle Tom's Cabin, and the book spells the
last name "St. Clare", never expanded to "Saint".

In any case, suggesting etymology as being decisive for names seems to
me problematic in many ways, especially in Canada where we've
adopted/mangled many names and phrases from other languages.

Thanks,
--Jarek

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

Re: [Talk-ca] Saints in street names in Ontario

[Andy Townsend]

On 15/03/2019 16:58, Martin Chalifoux via Talk-ca wrote:
The word is definitely Saint. St is a contraction and neither proper 
English or French.


I can't comment about Canadian English, but "St" in a placename in 
British English is perfectly OK - St Albans is correct; "Saint Albans" 
is not.


Not that this has any relevant to Canadian placenames of course 
(especially those with a French derivation - "Saint-Denis" is of course 
correct there).


Best Regards,

Andy



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

Re: [Talk-ca] Saints in street names in Ontario

[Danny McDonald]

I agree with Jarek, St. should generally not be expanded for English
Canadian street names.  The proper spelling is St. (or St) even if the
pronunciation is Saint.  name:pronunciation (
https://wiki.openstreetmap.org/wiki/Key:name:pronunciation) is a tag that
can capture the pronunciation, if desired.

In Quebec, I believe it is different, and St often is expanded.
DannyMcD
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Saints in street names in Ontario

[Kevin Farrugia]

No, I'm referring to the official records of street names held by
municipalities. In many cases, at least in newer developments, they seem to
be abbreviated. If it's officially short form then it would be incorrect to
say it's Saint.

---
Kevin Farrugia

On Fri, Mar 15, 2019, 1:08 PM Martin Chalifoux 
wrote:

> I think the osm database should use proper words. Abbreviating is a
> rendering issue and many rendering engines can do that. Space constraints
> on signage dictate the use of abbreviations for those.
>
>
>
> On Mar 15, 2019, at 12:50, Kevin Farrugia  wrote:
>
> Hi Jarek,
>
> I agree that of the sign has a short form for saint then it should be that
> way on the map too, as the sign text comes from the official records of
> street names.
>
> I think St. Is better with a period as it makes it less ambiguous to it
> being an abbreviation and it may help screen readers or spoken directions
> in maps provide the right information.
>
> ---
> Kevin F
>
>
> On Fri, Mar 15, 2019, 12:44 PM Jarek Piórkowski 
> wrote:
>
>> Hi all,
>>
>> A couple of months back we established a consensus [1] that "St." in
>> Canadian English city names should not be expanded.
>>
>> I have been thinking of having the same for street names, and would
>> like to ask people's opinions.
>>
>> My main motivation is St. Clair Avenue in Toronto. Every city source I
>> could find and every street sign I saw in Mapillary says "St. Clair"
>> or "St Clair". The TTC stations and routes are consistently "St
>> Clair". The City uses "St. Clair Avenue West" in official documents
>> like [2]. Geobase in Toronto has "St Clair Avenue West" , "St Clarens
>> Avenue", and "St Helens Avenue". Currently most of the street is named
>> "Saint Clair Avenue West/East" in OpenStreetMap, but this is changed
>> for some parts of the road every now and then.
>>
>> As a local mapper I would say that "St. Clair Avenue West" is the full
>> name. Unlike with "Av", "Ave", "W", the "St" in "St Clair" is IMO not
>> an abbreviation.
>>
>> Across the Golden Horseshoe names starting with "St. " or "St " seem
>> to be a bit more common [3] than "Saint" [4], I gather the
>> acronym-expanders have not looked as much outside of Toronto.
>>
>> Would we have Ontario community consensus for a statement along the lines
>> of:
>> "Where "St." or "St" is normally used in the full street name, it
>> should not be expanded to "Saint" even if pronounced so"?
>>
>> (I don't know what the naming conventions are in other provinces, so I
>> focus on Ontario for now. Apologies for being Ontario-centric, but I
>> don't know of a better venue that is Ontario-specific. I'll post links
>> to this message in wiki talk pages for Ontario, WikiProject_Canada,
>> and Canadian_tagging_guidelines.)
>>
>> As part of my checks I also looked at London UK, which I gather might
>> be the most-intensively-mapped English-speaking city. (Recommendations
>> for better-mapped English-speaking cities welcome). Searching for
>> "St." in road names [5], it has street names for bigger streets like
>> "St. John Street" and "St. Pancras Way"; [6] has name="St. Paul's
>> Road" + not:name="Saint Paul's Road" and has had so for 5 years.
>> Compare with searching for "Saint" [7] which also has some hits,
>> suggesting that both can be valid depending on what is signed and
>> used. (Or maybe it's just inconsistent.)
>>
>> [1]
>> https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Municipality_Names
>> [2]
>> https://www.toronto.ca/legdocs/mmis/2016/ey/bgrd/backgroundfile-92339.pdf
>> [3] https://overpass-turbo.eu/s/H1M
>> [4] https://overpass-turbo.eu/s/H1P
>> [5] https://overpass-turbo.eu/s/GPh
>> [6] https://osm.org/way/230843467
>> [7] https://overpass-turbo.eu/s/GPi
>>
>> Thanks,
>> --Jarek
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Saints in street names in Ontario

[Martin Chalifoux via Talk-ca]

I think the osm database should use proper words. Abbreviating is a rendering 
issue and many rendering engines can do that. Space constraints on signage 
dictate the use of abbreviations for those. 



> On Mar 15, 2019, at 12:50, Kevin Farrugia  wrote:
> 
> Hi Jarek,
> 
> I agree that of the sign has a short form for saint then it should be that 
> way on the map too, as the sign text comes from the official records of 
> street names. 
> 
> I think St. Is better with a period as it makes it less ambiguous to it being 
> an abbreviation and it may help screen readers or spoken directions in maps 
> provide the right information.
> 
> ---
> Kevin F
> 
> 
>> On Fri, Mar 15, 2019, 12:44 PM Jarek Piórkowski  wrote:
>> Hi all,
>> 
>> A couple of months back we established a consensus [1] that "St." in
>> Canadian English city names should not be expanded.
>> 
>> I have been thinking of having the same for street names, and would
>> like to ask people's opinions.
>> 
>> My main motivation is St. Clair Avenue in Toronto. Every city source I
>> could find and every street sign I saw in Mapillary says "St. Clair"
>> or "St Clair". The TTC stations and routes are consistently "St
>> Clair". The City uses "St. Clair Avenue West" in official documents
>> like [2]. Geobase in Toronto has "St Clair Avenue West" , "St Clarens
>> Avenue", and "St Helens Avenue". Currently most of the street is named
>> "Saint Clair Avenue West/East" in OpenStreetMap, but this is changed
>> for some parts of the road every now and then.
>> 
>> As a local mapper I would say that "St. Clair Avenue West" is the full
>> name. Unlike with "Av", "Ave", "W", the "St" in "St Clair" is IMO not
>> an abbreviation.
>> 
>> Across the Golden Horseshoe names starting with "St. " or "St " seem
>> to be a bit more common [3] than "Saint" [4], I gather the
>> acronym-expanders have not looked as much outside of Toronto.
>> 
>> Would we have Ontario community consensus for a statement along the lines of:
>> "Where "St." or "St" is normally used in the full street name, it
>> should not be expanded to "Saint" even if pronounced so"?
>> 
>> (I don't know what the naming conventions are in other provinces, so I
>> focus on Ontario for now. Apologies for being Ontario-centric, but I
>> don't know of a better venue that is Ontario-specific. I'll post links
>> to this message in wiki talk pages for Ontario, WikiProject_Canada,
>> and Canadian_tagging_guidelines.)
>> 
>> As part of my checks I also looked at London UK, which I gather might
>> be the most-intensively-mapped English-speaking city. (Recommendations
>> for better-mapped English-speaking cities welcome). Searching for
>> "St." in road names [5], it has street names for bigger streets like
>> "St. John Street" and "St. Pancras Way"; [6] has name="St. Paul's
>> Road" + not:name="Saint Paul's Road" and has had so for 5 years.
>> Compare with searching for "Saint" [7] which also has some hits,
>> suggesting that both can be valid depending on what is signed and
>> used. (Or maybe it's just inconsistent.)
>> 
>> [1] 
>> https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Municipality_Names
>> [2] https://www.toronto.ca/legdocs/mmis/2016/ey/bgrd/backgroundfile-92339.pdf
>> [3] https://overpass-turbo.eu/s/H1M
>> [4] https://overpass-turbo.eu/s/H1P
>> [5] https://overpass-turbo.eu/s/GPh
>> [6] https://osm.org/way/230843467
>> [7] https://overpass-turbo.eu/s/GPi
>> 
>> Thanks,
>> --Jarek
>> 
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Saints in street names in Ontario

[Kevin Farrugia]

However, the street name is legally "St." in almost all cases, so saint is
wrong.

---
Kevin Farrugia

On Fri, Mar 15, 2019, 1:00 PM Martin Chalifoux via Talk-ca <
talk-ca@openstreetmap.org> wrote:

> The word is definitely Saint. St is a contraction and neither proper
> English or French. It has the same Latin roots as sanctification and
> similar words.
>
> Similarly Av is a contraction for Avenue and not a word.
>
>
> https://en.m.wikipedia.org/wiki/Abbreviation
>
>
>
> On Mar 15, 2019, at 12:42, Jarek Piórkowski  wrote:
>
> Hi all,
>
> A couple of months back we established a consensus [1] that "St." in
> Canadian English city names should not be expanded.
>
> I have been thinking of having the same for street names, and would
> like to ask people's opinions.
>
> My main motivation is St. Clair Avenue in Toronto. Every city source I
> could find and every street sign I saw in Mapillary says "St. Clair"
> or "St Clair". The TTC stations and routes are consistently "St
> Clair". The City uses "St. Clair Avenue West" in official documents
> like [2]. Geobase in Toronto has "St Clair Avenue West" , "St Clarens
> Avenue", and "St Helens Avenue". Currently most of the street is named
> "Saint Clair Avenue West/East" in OpenStreetMap, but this is changed
> for some parts of the road every now and then.
>
> As a local mapper I would say that "St. Clair Avenue West" is the full
> name. Unlike with "Av", "Ave", "W", the "St" in "St Clair" is IMO not
> an abbreviation.
>
> Across the Golden Horseshoe names starting with "St. " or "St " seem
> to be a bit more common [3] than "Saint" [4], I gather the
> acronym-expanders have not looked as much outside of Toronto.
>
> Would we have Ontario community consensus for a statement along the lines
> of:
> "Where "St." or "St" is normally used in the full street name, it
> should not be expanded to "Saint" even if pronounced so"?
>
> (I don't know what the naming conventions are in other provinces, so I
> focus on Ontario for now. Apologies for being Ontario-centric, but I
> don't know of a better venue that is Ontario-specific. I'll post links
> to this message in wiki talk pages for Ontario, WikiProject_Canada,
> and Canadian_tagging_guidelines.)
>
> As part of my checks I also looked at London UK, which I gather might
> be the most-intensively-mapped English-speaking city. (Recommendations
> for better-mapped English-speaking cities welcome). Searching for
> "St." in road names [5], it has street names for bigger streets like
> "St. John Street" and "St. Pancras Way"; [6] has name="St. Paul's
> Road" + not:name="Saint Paul's Road" and has had so for 5 years.
> Compare with searching for "Saint" [7] which also has some hits,
> suggesting that both can be valid depending on what is signed and
> used. (Or maybe it's just inconsistent.)
>
> [1]
> https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Municipality_Names
> [2]
> https://www.toronto.ca/legdocs/mmis/2016/ey/bgrd/backgroundfile-92339.pdf
> [3] https://overpass-turbo.eu/s/H1M
> [4] https://overpass-turbo.eu/s/H1P
> [5] https://overpass-turbo.eu/s/GPh
> [6] https://osm.org/way/230843467
> [7] https://overpass-turbo.eu/s/GPi
>
> Thanks,
> --Jarek
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Saints in street names in Ontario

[Nate Wessel]

Don't forget about the various alternative naming tags like alt_name=* 
, short_name=* 
, loc_name=*, and also 
name:etymology=* 
 to make things 
absolutely clear.


Having either spelling in one of these alternatives as appropriate would 
likely satisfy any dissenters and make both the full and abbreviated 
name searchable.


Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 3/15/19 12:58 PM, Martin Chalifoux via Talk-ca wrote:
The word is definitely Saint. St is a contraction and neither proper 
English or French. It has the same Latin roots as sanctification and 
similar words.


Similarly Av is a contraction for Avenue and not a word.


https://en.m.wikipedia.org/wiki/Abbreviation



On Mar 15, 2019, at 12:42, Jarek Piórkowski > wrote:



Hi all,

A couple of months back we established a consensus [1] that "St." in
Canadian English city names should not be expanded.

I have been thinking of having the same for street names, and would
like to ask people's opinions.

My main motivation is St. Clair Avenue in Toronto. Every city source I
could find and every street sign I saw in Mapillary says "St. Clair"
or "St Clair". The TTC stations and routes are consistently "St
Clair". The City uses "St. Clair Avenue West" in official documents
like [2]. Geobase in Toronto has "St Clair Avenue West" , "St Clarens
Avenue", and "St Helens Avenue". Currently most of the street is named
"Saint Clair Avenue West/East" in OpenStreetMap, but this is changed
for some parts of the road every now and then.

As a local mapper I would say that "St. Clair Avenue West" is the full
name. Unlike with "Av", "Ave", "W", the "St" in "St Clair" is IMO not
an abbreviation.

Across the Golden Horseshoe names starting with "St. " or "St " seem
to be a bit more common [3] than "Saint" [4], I gather the
acronym-expanders have not looked as much outside of Toronto.

Would we have Ontario community consensus for a statement along the 
lines of:

"Where "St." or "St" is normally used in the full street name, it
should not be expanded to "Saint" even if pronounced so"?

(I don't know what the naming conventions are in other provinces, so I
focus on Ontario for now. Apologies for being Ontario-centric, but I
don't know of a better venue that is Ontario-specific. I'll post links
to this message in wiki talk pages for Ontario, WikiProject_Canada,
and Canadian_tagging_guidelines.)

As part of my checks I also looked at London UK, which I gather might
be the most-intensively-mapped English-speaking city. (Recommendations
for better-mapped English-speaking cities welcome). Searching for
"St." in road names [5], it has street names for bigger streets like
"St. John Street" and "St. Pancras Way"; [6] has name="St. Paul's
Road" + not:name="Saint Paul's Road" and has had so for 5 years.
Compare with searching for "Saint" [7] which also has some hits,
suggesting that both can be valid depending on what is signed and
used. (Or maybe it's just inconsistent.)

[1] 
https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Municipality_Names
[2] 
https://www.toronto.ca/legdocs/mmis/2016/ey/bgrd/backgroundfile-92339.pdf

[3] https://overpass-turbo.eu/s/H1M
[4] https://overpass-turbo.eu/s/H1P
[5] https://overpass-turbo.eu/s/GPh
[6] https://osm.org/way/230843467
[7] https://overpass-turbo.eu/s/GPi

Thanks,
--Jarek

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


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

Re: [Talk-ca] Saints in street names in Ontario

[Martin Chalifoux via Talk-ca]

The word is definitely Saint. St is a contraction and neither proper English or 
French. It has the same Latin roots as sanctification and similar words. 

Similarly Av is a contraction for Avenue and not a word. 


https://en.m.wikipedia.org/wiki/Abbreviation



> On Mar 15, 2019, at 12:42, Jarek Piórkowski  wrote:
> 
> Hi all,
> 
> A couple of months back we established a consensus [1] that "St." in
> Canadian English city names should not be expanded.
> 
> I have been thinking of having the same for street names, and would
> like to ask people's opinions.
> 
> My main motivation is St. Clair Avenue in Toronto. Every city source I
> could find and every street sign I saw in Mapillary says "St. Clair"
> or "St Clair". The TTC stations and routes are consistently "St
> Clair". The City uses "St. Clair Avenue West" in official documents
> like [2]. Geobase in Toronto has "St Clair Avenue West" , "St Clarens
> Avenue", and "St Helens Avenue". Currently most of the street is named
> "Saint Clair Avenue West/East" in OpenStreetMap, but this is changed
> for some parts of the road every now and then.
> 
> As a local mapper I would say that "St. Clair Avenue West" is the full
> name. Unlike with "Av", "Ave", "W", the "St" in "St Clair" is IMO not
> an abbreviation.
> 
> Across the Golden Horseshoe names starting with "St. " or "St " seem
> to be a bit more common [3] than "Saint" [4], I gather the
> acronym-expanders have not looked as much outside of Toronto.
> 
> Would we have Ontario community consensus for a statement along the lines of:
> "Where "St." or "St" is normally used in the full street name, it
> should not be expanded to "Saint" even if pronounced so"?
> 
> (I don't know what the naming conventions are in other provinces, so I
> focus on Ontario for now. Apologies for being Ontario-centric, but I
> don't know of a better venue that is Ontario-specific. I'll post links
> to this message in wiki talk pages for Ontario, WikiProject_Canada,
> and Canadian_tagging_guidelines.)
> 
> As part of my checks I also looked at London UK, which I gather might
> be the most-intensively-mapped English-speaking city. (Recommendations
> for better-mapped English-speaking cities welcome). Searching for
> "St." in road names [5], it has street names for bigger streets like
> "St. John Street" and "St. Pancras Way"; [6] has name="St. Paul's
> Road" + not:name="Saint Paul's Road" and has had so for 5 years.
> Compare with searching for "Saint" [7] which also has some hits,
> suggesting that both can be valid depending on what is signed and
> used. (Or maybe it's just inconsistent.)
> 
> [1] 
> https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Municipality_Names
> [2] https://www.toronto.ca/legdocs/mmis/2016/ey/bgrd/backgroundfile-92339.pdf
> [3] https://overpass-turbo.eu/s/H1M
> [4] https://overpass-turbo.eu/s/H1P
> [5] https://overpass-turbo.eu/s/GPh
> [6] https://osm.org/way/230843467
> [7] https://overpass-turbo.eu/s/GPi
> 
> Thanks,
> --Jarek
> 
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-fr] Places PMR ?

[Vincent Bergeot]

Bonjour,

bon du coup je boucle et je ne sais pas trop comment déboucler :)

Je parle ici seulement du tag amenity=parking_space pour 1 seule place 
de parking réservée pour des personnes à mobilité réduite (titulaire 
d'un macaron)


Plusieurs schémas (je mets de coté wheelchair qui va qualifier 
l'effectivité de l'accessibilité en fauteuil) et si on regarde les 
combinaisons : 
https://taginfo.openstreetmap.org/tags/amenity=parking_space#combinations


1. amenity=parking_space + capacity:disabled=*-> un peu plus de 10 000
   occurrence
2. amenity=parking_space + parking_space=disabled -> un peu moins de 10
   000 occurences
3. amenity=parking_space + disabled=yes/designated -> ?
4. amenity=parking_space + access:disabled=designated  -> ?
5. amenity=parking_space + wheelchair -> 19500 avec 16000 yes

5 -> c'est l'effectivité de l'accessibilité en fauteuil donc à part.

3 et 4 pas beaucoup d'occurrences, du moins sur la page

1 et 2 assez proche

1 -> le tag capacity:disabled=* est plus adapté à un ensemble de places 
dont une partie capacity:disabled=*


2 -> "pas cohérent avec parking=surface/sous-terrain" mais une place de 
parking en souterrain ou silo fera partie d'un amenity=parking qui lui 
sera taggué parking=surface/sous-terrain -> je ne suis pas sur que les 
valeurs des clés parking et parking_space aient besoin d'être cohérentes.


Il est fait référence dans la page de proposition 
(https://wiki.openstreetmap.org/wiki/Proposed_features/parking#Parking_space) 
à la fois au place de parking pour le carpool, disabled, ...


Bon j'arrête, je ne suis pas sur d'avoir fini de boucler !!!

à vous lire !




Le 11/03/2019 à 11:30, PanierAvide a écrit :


Bonjour,

Le tag capacity=* sur amenity=parking_space est utilisable si 
l'emprise comporte plusieurs places. Mais le wiki précise aussi que 
les tags capacity:*=* ne sont pas utilisables sur les parking_space, 
qu'il faut plutôt utiliser access:*=*...


Donc à priori ce serait amenity=parking_space + access=no + 
access:disabled=designated + wheelchair=* (+ capacity=* si plusieurs 
places collées). Ça en fait des tags pour indiquer une place PMR ! 
Utiliser parking_space=disabled simplifierait la chose, ou pas si on 
se retrouve à devoir le combiner avec les "anciens" tags.


Cordialement,

Adrien P.
Le 11/03/2019 à 10:32, Vincent Bergeot a écrit :

Bonjour,
je reprends ce fil car la question me hante (au moins !!!)/

Dans le cas d'une *place individuelle de parking de type 
stationnement réservé pour les personnes handicapées ou à mobilité 
réduite* :


  * amenity=parking_space OK -> cela décrit 1 place
  * capacity:disabled=1 je ne comprends pas car on vient déjà de dire
que c'est 1 avec parking_space (puisque que cela décrit justement
une place), donc j'ai tendance à penser que c'est par défaut
capacity=1 et que dans le cas de amenity=parking_space cela n'a
pas de "sens" de définir des capacity
  * parking_space=disabled (effectivement peu renseigné sur le wiki
et utilisé surtout en europe),
  * wheelchair venant renseigner alors l'effectivité de
l'accessibilité en fauteuil

Ce que je ne vois pas c'est pourquoi parking_space=* ne serait pas 
plus utilisé (pour disabled mais sans doute aussi pour les places 
familles devant les supermarchés, les places réservées, carpool, 
comme d'ailleurs l'illustre la photo de la page wiki :

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space)

au plaisir de vous lire




Le 19/03/2018 à 11:06, PanierAvide a écrit :


Bonjour Marc et Jérôme,

Merci pour vos deux réponses, ça montre bien une divergence des 
pratiques :-) Effectivement l'ambiguïté de la représentation porte 
sur les places individuelles, le cas du décompte sur un parking 
global est pour le coup explicite avec capacity:disabled=*.


Malgré la confusion, de ce que je comprends, il y a quand même 
consensus sur les points suivants :


- wheelchair=yes indique l'accessibilité réelle sur le terrain de la 
place

- Il vaudrait mieux se baser des tags orientés access=*

Après je vois qu'il y a pléthore de valeurs possibles si on part sur 
la logique access. Pourquoi un combo amenity=parking_space + 
access=no + disabled=yes/designated ne serait-il pas suffisant (en 
ajoutant éventuellement du capacity:disabled pour un groupe de places) ?


Cordialement,

Adrien.


Le 19/03/2018 à 10:51, Jérôme Seigneuret a écrit :

salut,

En clair on utilise capacity:disabled=1 sur la zone de parking ou 
un espace.  Le truc c'est que si tu englobes les capacités sur la 
zone et sur la place c'est une double info et un double comptage. 
En clair,
si tu mixes les deux il faut enlever les espaces dans la zone 
général et les décompter. parking_space utilise la relation site 
pour regrouper les places d'un parking. C'est du micro mapping


Pour info, le stationnement avec la CMI n'est pas Franco-Français 
et les règles à établir sont Européenne. Donc si le sujet coince il 
faudra le remonter sur  osm-talk


Pour le reste ça se base sur 

Re: [Talk-it] percorsi che attraversano piazze

[Cascafico Giovanni]

Presumo ci sia anche il problema del routing

Il ven 15 mar 2019, 17:39 demon_box  ha scritto:

> in corrispondenza di piazze che vengono attraversate da percorsi di tipo
> hiking piuttosto che ciclabili, trovo mappate all'uopo highway che in
> realtà
> non esistono, ma vi domando, se una delle regole d'oro di OSM è proprio che
> noi mappiamo ciò che esiste come risolviamo questi casi?
> a me comunque sembra sbagliato mappare una highway che non esiste soltanto
> per farci passare la relazione percorso!
> grazie
>
> --enrico
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-ca] Saints in street names in Ontario

[Kevin Farrugia]

Hi Jarek,

I agree that of the sign has a short form for saint then it should be that
way on the map too, as the sign text comes from the official records of
street names.

I think St. Is better with a period as it makes it less ambiguous to it
being an abbreviation and it may help screen readers or spoken directions
in maps provide the right information.

---
Kevin F


On Fri, Mar 15, 2019, 12:44 PM Jarek Piórkowski  wrote:

> Hi all,
>
> A couple of months back we established a consensus [1] that "St." in
> Canadian English city names should not be expanded.
>
> I have been thinking of having the same for street names, and would
> like to ask people's opinions.
>
> My main motivation is St. Clair Avenue in Toronto. Every city source I
> could find and every street sign I saw in Mapillary says "St. Clair"
> or "St Clair". The TTC stations and routes are consistently "St
> Clair". The City uses "St. Clair Avenue West" in official documents
> like [2]. Geobase in Toronto has "St Clair Avenue West" , "St Clarens
> Avenue", and "St Helens Avenue". Currently most of the street is named
> "Saint Clair Avenue West/East" in OpenStreetMap, but this is changed
> for some parts of the road every now and then.
>
> As a local mapper I would say that "St. Clair Avenue West" is the full
> name. Unlike with "Av", "Ave", "W", the "St" in "St Clair" is IMO not
> an abbreviation.
>
> Across the Golden Horseshoe names starting with "St. " or "St " seem
> to be a bit more common [3] than "Saint" [4], I gather the
> acronym-expanders have not looked as much outside of Toronto.
>
> Would we have Ontario community consensus for a statement along the lines
> of:
> "Where "St." or "St" is normally used in the full street name, it
> should not be expanded to "Saint" even if pronounced so"?
>
> (I don't know what the naming conventions are in other provinces, so I
> focus on Ontario for now. Apologies for being Ontario-centric, but I
> don't know of a better venue that is Ontario-specific. I'll post links
> to this message in wiki talk pages for Ontario, WikiProject_Canada,
> and Canadian_tagging_guidelines.)
>
> As part of my checks I also looked at London UK, which I gather might
> be the most-intensively-mapped English-speaking city. (Recommendations
> for better-mapped English-speaking cities welcome). Searching for
> "St." in road names [5], it has street names for bigger streets like
> "St. John Street" and "St. Pancras Way"; [6] has name="St. Paul's
> Road" + not:name="Saint Paul's Road" and has had so for 5 years.
> Compare with searching for "Saint" [7] which also has some hits,
> suggesting that both can be valid depending on what is signed and
> used. (Or maybe it's just inconsistent.)
>
> [1]
> https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Municipality_Names
> [2]
> https://www.toronto.ca/legdocs/mmis/2016/ey/bgrd/backgroundfile-92339.pdf
> [3] https://overpass-turbo.eu/s/H1M
> [4] https://overpass-turbo.eu/s/H1P
> [5] https://overpass-turbo.eu/s/GPh
> [6] https://osm.org/way/230843467
> [7] https://overpass-turbo.eu/s/GPi
>
> Thanks,
> --Jarek
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[OSM-talk-fr] améliorer les panneaux entrée et sortie de ville

[Jérôme Seigneuret]

Salut,

J'aimerai améliorer les affichage pour les panneaux d'entrée et sortie de
ville.


voici un cas  sur le même panneaux
direction=310
highway=traffic_sign
name:2=Jouy-en-Josas (sortie)
name=Les Loges-en-Josas (entrée)
traffic_sign=city_limit

merci

Jérôme
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-ca] Saints in street names in Ontario

[Jarek Piórkowski]

Hi all,

A couple of months back we established a consensus [1] that "St." in
Canadian English city names should not be expanded.

I have been thinking of having the same for street names, and would
like to ask people's opinions.

My main motivation is St. Clair Avenue in Toronto. Every city source I
could find and every street sign I saw in Mapillary says "St. Clair"
or "St Clair". The TTC stations and routes are consistently "St
Clair". The City uses "St. Clair Avenue West" in official documents
like [2]. Geobase in Toronto has "St Clair Avenue West" , "St Clarens
Avenue", and "St Helens Avenue". Currently most of the street is named
"Saint Clair Avenue West/East" in OpenStreetMap, but this is changed
for some parts of the road every now and then.

As a local mapper I would say that "St. Clair Avenue West" is the full
name. Unlike with "Av", "Ave", "W", the "St" in "St Clair" is IMO not
an abbreviation.

Across the Golden Horseshoe names starting with "St. " or "St " seem
to be a bit more common [3] than "Saint" [4], I gather the
acronym-expanders have not looked as much outside of Toronto.

Would we have Ontario community consensus for a statement along the lines of:
"Where "St." or "St" is normally used in the full street name, it
should not be expanded to "Saint" even if pronounced so"?

(I don't know what the naming conventions are in other provinces, so I
focus on Ontario for now. Apologies for being Ontario-centric, but I
don't know of a better venue that is Ontario-specific. I'll post links
to this message in wiki talk pages for Ontario, WikiProject_Canada,
and Canadian_tagging_guidelines.)

As part of my checks I also looked at London UK, which I gather might
be the most-intensively-mapped English-speaking city. (Recommendations
for better-mapped English-speaking cities welcome). Searching for
"St." in road names [5], it has street names for bigger streets like
"St. John Street" and "St. Pancras Way"; [6] has name="St. Paul's
Road" + not:name="Saint Paul's Road" and has had so for 5 years.
Compare with searching for "Saint" [7] which also has some hits,
suggesting that both can be valid depending on what is signed and
used. (Or maybe it's just inconsistent.)

[1] 
https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Municipality_Names
[2] https://www.toronto.ca/legdocs/mmis/2016/ey/bgrd/backgroundfile-92339.pdf
[3] https://overpass-turbo.eu/s/H1M
[4] https://overpass-turbo.eu/s/H1P
[5] https://overpass-turbo.eu/s/GPh
[6] https://osm.org/way/230843467
[7] https://overpass-turbo.eu/s/GPi

Thanks,
--Jarek

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

[Talk-it] percorsi che attraversano piazze

[demon_box]

in corrispondenza di piazze che vengono attraversate da percorsi di tipo
hiking piuttosto che ciclabili, trovo mappate all'uopo highway che in realtà
non esistono, ma vi domando, se una delle regole d'oro di OSM è proprio che
noi mappiamo ciò che esiste come risolviamo questi casi?
a me comunque sembra sbagliato mappare una highway che non esiste soltanto
per farci passare la relazione percorso!
grazie

--enrico




--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [OSM-talk-fr] Tuiles cadatsre sans réponse sur JOSM

[Jérôme Seigneuret]

tu es sous quoi? windows linux mac?


Le ven. 15 mars 2019 à 15:20, Jozeph via Talk-fr 
a écrit :

> Bonjour,
>
> Oui je rencontre ce problème depuis hier avec le message :
>
> "Erreur lors du chargement des tuiles :
> javax.net.ssl.SSLProtocolException handshake alert: unrecognized_name"
>
> Je ne sais pas introduire le paramètre supplémentaire dans le lancement de 
> JOSM comme indiqué par Denis.
>
> Que me conseillez-vous ?
>
> Avec mes remerciements.
>
> Joseph
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] R: Tag place

[Andy Townsend]

On 24/02/2019 12:11, Andy Townsend wrote:

On 23/02/2019 22:39, mbranco2 wrote:
A me basta la disponibilità di Fayor a rimuovere manualmente le sue 
modifiche, quindi dico di non fare il revert.


OK - we'll wait a bit and give him time to do that.

("OK - aspettiamo un po 'e dargli il tempo di farlo.")


Just following up this mail from a few weeks ago - have these places now 
been resolved so that the community is happy, or is there more work to do?


Best Regards,

Andy

(traduzione automatica per comodità)

Seguendo questa mail di poche settimane fa, questi posti sono stati 
risolti in modo che la comunità sia felice o ci sia ancora del lavoro da 
fare?


I migliori saluti,

Andy



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

Re: [OSM-talk-fr] Quartiers à Paris

[Léo El Amri via Talk-fr]

On 15/03/2019 16:59, marc marc wrote:
> Le 15.03.19 à 16:29, Léo El Amri via Talk-fr a écrit :
>> catégoriser les découpages
> 
> je pense que la majorité existent déjà.
> 
> Par exemple pour le quartier de Paris,
> le populaire (celui avec un place=*) ayant une limite
> que personne ne semble contester, il peux facilement
> être tagé comme une aire : c'est la seule façon de transformer
> l'étendue bleue de l'image précédente en donnée osm.
> 
> sinon on arrive à un résultat incohérent : on dit que le quartier 
> populaire mérite d'être ajouté dans osm car différent du découpage 
> administratif du même nom, mais l'ajout dans osm ne montre pas cette 
> différence et mettre une note sur les 2 objets ne permet pas plus
> "d'utiliser" cette différence.

Les aires sont définies par des ways fermés et tagués avec area=yes.

Techniquement, dans mon exemple, je souhaitais taguer les relations, ou
si il n'y en a pas, les area ou les nodes. L'idée est d'avoir un tag qui
permette de catégoriser la relation, area ou node, par exemple:
"type_decoupage=admin" pour les infos tirées du cadastre, la maire ou
que sais-je ou "type_decoupage=usuel" pour les découpages "populaires"
(Les fameux quartiers de Paris).

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

Re: [OSM-talk-fr] adressage dans les zones sans nom de voie - exemple un aérodrome

[Jérôme Seigneuret]

Marc, J'ai standardisé tous les nom de résidence ainsi. J'ai pas de
consenssus à ce niveau et c'est aussi le même problème pour les ZI, ZA, ZAC
...

 place=neighbourhood est trop aléatoire en niveau. Je l'ai utilisé et j'en
reviens. Problème de définition entre quartier et info en grande ville ou
village... après je suis d'accord sur le fait de changer en addr:place +
place=city_block ou residential

Le ven. 15 mars 2019 à 16:55, marc marc  a
écrit :

> de l'exemple de ton ticket, par ex
> https://www.openstreetmap.org/node/6332817525
> je pense qu'il est + correcte de changer
> addr:street="Résidence l'Orée de Marly" en addr:place
> et mettre un place=neighbourhood name=Résidence l'Orée de Marly.
> Dans certains autres cas place=city_block peux être + adapté.
>
> Le 15.03.19 à 16:19, Jérôme Seigneuret a écrit :
> > ok c'est fait
> >
> > Le ven. 15 mars 2019 à 14:16, Vincent de Château-Thierry
> > mailto:osm.v...@free.fr>> a écrit :
> >
> >
> >  > De: "Jérôme Seigneuret"  > >
> >  >
> >  > PS hors optique Lieudit tu as le même problème sur les gros
> complexes
> >  > résidentielle avec numéro voir numéro + Lettre, Numéro plus nom de
> >  > batiment et sans pour autant avoir un nm de rue. En région
> >  > parisienne je suis confronté régulièrement à ce problème. Certains
> >  > on patché ça en mettant le nom de la résidence sur la voirie et
> fait
> >  > de même sur les numéros d'adresse. Ducoup il y a pas mal de nom de
> >  > voie dans BANO avec lotissement * ou résidence * qui n'ont pas de
> >  > réelle existance.
> >  >
> >  > As tu pris ça en compte dans la V2?
> >
> > Je n'ai pas touché aux logiques métier dans la v2, c'est surtout une
> > version qui permet de mieux coller aux versions courantes de Fantoir
> > et Cadastre durablement, en profitant des publications sur
> > data.gouv.fr . Donc je ne pense pas que ça soit
> > plus géré qu'avant, mais je veux bien les exemples dont tu parles
> > histoire d'appréhender le sujet concrètement. Tu peux en indiquer
> > ici, ou directement créer un ticket =>
> > https://github.com/osm-fr/bano/issues/new
> >
> > merci
> > vincent
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
> >
> >
> > --
> > Cordialement,
> > Jérôme Seigneuret
> >
> > ___
> > 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-ca] Building Import

[Andrew Lester]

I disagree. Silence won't solve anything. 

I'm speaking here as a local BC mapper, and I strongly disagree with these 
recent imports. I thought we had a general consensus that we'd discuss this as 
a community and figure things out before restarting the import, but it seems 
that some mappers don't like having to wait or deal with other people. 
Considering that Danny seems to consider orthogonal buildings to be outright 
wrong (a position that I strongly disagree with and I think some others do 
too), there's clearly still some discussion required before imports can be 
started again. Sure, you could go ahead and import anyway contrary to other 
community members' wishes, but that sure won't make you any friends and you run 
the risk of having your changesets reverted if the data quality is too poor or 
violates the import guidelines. 

Please, please, please, let's hammer things out first before we import any of 
this data. The buildings aren't going anywhere, so there's no need to rush poor 
data into the database. If you're itching to map some things, go for a walk and 
map some addresses and businesses near you. 

Andrew 
Victoria, BC, Canada 



From: "Danny McDonald"  
To: "talk-ca"  
Sent: Friday, March 15, 2019 8:48:55 AM 
Subject: Re: [Talk-ca] Building Import 

OK, so this discussion has gone a bit off the rails. In terms of the DWG, this 
has all happened so fast - the referral to the DWG was less than 2 hours after 
the initial message, and was not in response to any actual edits I made after 
receiving Pierre's stop message. 
I suggest that we all stop emailing this list for the rest of the day, given 
the high level of tension on both sides. I will not be importing anything for 
the next week (at the very least), and I don't think anyone else will either. 
DannyMcD 

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

Re: [Talk-it] Utente che ignora i suggerimenti

[Martin Koppenhoefer]

Ciao Alexander,


Am Do., 14. März 2019 um 16:11 Uhr schrieb Alexander Shilin <
dmitri.alex.ji...@gmail.com>:

> Ehi, ciao Martin
>
> si, è vero, il Centro storico dell'Aquila e pieno dei Palazzi storici -
> dal medioevo e renascimento. Alcuni sono in uso del comune, altri no. Ma
> tutti di valore artistico. Penso che solo questi di "valore artistico"
> hanno il tag "Palazzo" (palace) o (castle).
>



si, ma il wiki dice, "palace" si usa per le "grande residenze in città, in
particolare quelli reali, del capo dello stato oppure di altre "altezze"
come un vescovo oppure arcivescovo".
https://wiki.openstreetmap.org/wiki/Key:castle_type (in tedesco "Schloß")

Invece per un palazzo di una famiglia potente, ma non reale, ci sono altri
castle_type come "stately", "manor", e forse altri da definire. "palace"
per qualsiasi palazzo (anche quelli degni di nota) è esagerato.




> Abiamo pensato di realizzare per gli Aquilani un sistema con cui si può
> trovare faccile gli vari uffici dell Comune dell'Aquila. L'Indoormapping
> sembra la soluzione giusta. Dove sono gli uffici e come si chiaman e altri
> dati abbiamo noi.
>


certamente, è un'iniziativa benvenuta, dal mio punto di vista la
discussione è solo sul "come".



> Solo la "traduzione" dei dati in una visualizzazione comprensibile per gli
> utenti del OSM fa problemi.
>


si, questo è il punto delicato, bisogna lavorarci sul come inserire i dati
/ come tradurre le informazioni.



> Tutti esemii di Indoormapping che abbiamo trovato in tuttu il mondo erano
> difficile da capire. Pieno di info ma alla fine non verramente usabile per
> una facile navigazione indoor.
>


la cosa importante penso sia avere le informazioni separate e strutturate
come possano essere utili. Se ci sono 10 uffici (o a dirittura 40 come in
un esempio), io farei un oggetto per ogni ufficio / stanza, aggiungerei
l'indirizzo specifico (numero di stanza, numero di piano, numero telefonico
se pubblico, email di contatto, orari di apertura al pubblico, ecc.), alla
sua "vera" posizione all'interno dell'edificio, per esempio come nodi
dentro un poligono per la sede dove si trovano. Se invece gli orari sono li
stessi per tutti gli uffici della sede, potresti anche mettere i relativi
tags alla sede piùttosto che al singolo ufficio. Invece un esempio reale
dell'Aquila postato qui in lista era un unico nodo con 40 uffici insieme, e
dei tags del tutto inusuali (numeri come chiavi).


PS: Che cosa è SEO ?


search engine optimization = spam per ingannare i motori di ricerca

Ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-ca] Building Import

[Frederik Ramm]

Hi,

On 15.03.19 16:23, Danny McDonald wrote:
> I think many people on this list fundamentally misunderstand the way OSM
> operates.  Most OSM contributions are made by individuals who see a
> gap/mistake in the data and fix it. 

True!

> It is not a "community process"
> where contributions are made by a group of "local mappers" (although
> this sometimes happens).  

True!

As long as we're talking normal, everyday, "manual" mapping. Like, 100
edits a day, or maybe 1000 edits on a good day.

For things that go beyond a little mapping by the individual, we tend to
have processes, e.g. for imports, for automated edits, for organised edits.

The general idea behind the discuss-these-things-first rules is not that
one mapper is better than another, but quite the opposite: One mapper
alone can actually make stupid mistakes or suffer from bad judgement,
something that the larger community can help against.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Talk-ca] Building import in BC and Quebec

[John Whelan]

At the end of the day one would hope we are a community.  We are a large 
group with divergent opinions and to be honest there is a great deal of 
interest in non-mappers in this sort of data.


For example building data is being used in Tanzania to work out the 
optimal areas for group solar panels.  It can be used for many other 
things which may not be immediately apparent to a traditional paper 
based mapper.


With both the Stats Can released data and the Microsoft released data 
floating around some data is going to creep in anyway.


At the moment we have Tim taking responsibility for Montreal.

There seems to be a number of divergent views in Toronto so I think they 
should sit down and see if they can come to some sort of agreement.


We have Pierre and Nate who would appear to have different standards of 
what is acceptable to other mappers.  We have at least half a dozen 
mappers who support the import, shown by their imports. I can probably 
find a few more mappers who support the import if it comes to a simple vote.


I would suggest we try to best manage the process.  If that means the 
imported data is verified by another mapper I think that can be arranged.


Cheerio John

Yaro Shkvorets wrote on 2019-03-15 11:22 AM:
As an experienced local Ontario and Quebec mapper I don't see any 
major problems with Stats Can building quality. It's detailed and 
recent, it's the best dataset we could ever possibly get and it's far 
superior to Microsoft quality. Having many buildings with "almost 
square angles" in this dataset is not an issue as vast majority of 
such deviations cannot be seen with a naked eye. Unfortunately any 
orthogonalization algorithms will do more harm than good in such 
cases. Mapping for the Validator, just like mapping for the Renderer 
is a wrong way to map.
Issues were raised, issues were addressed in the import plan. If there 
are any problems with some mappers violating any specific import plan 
rules such issues need to be pointed out so they can adjust their 
workflow.

My 2 cents.

On Fri, Mar 15, 2019 at 10:55 AM Nate Wessel > wrote:


I just reported this to the data working group, in case you
haven't already. Hopefully they will step in!

Cheers,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban
Planning
NateWessel.com 

On 3/15/19 10:30 AM, Pierre Béland wrote:

Réponse immédiate avec refus de discussion de la part de
DannyMcD_imports. Celui-ci indique qu'il prévoit continuer l'import.
voir https://www.openstreetmap.org/changeset/67686901

There was a discussion, issues were raised, the problems (to the
extent that they existed at all) have been addressed. I plan to
continue importing, unless a *specific* valid issue is raised.
Please do not contact me again unless you have such an issue.


La prochaine étape est je pense de contacter le Data Working Group.


Pierre



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



--
Best Regards,
          Yaro Shkvorets
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


--
Sent from Postbox 

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

Re: [OSM-talk-fr] Quartiers à Paris

[marc marc]

De: "althio" 
 > si quelqu'un veut supprimer le quartier administratif

c'est une caricature surement volontaire pour provoquer
les partisans de l'inverse mais cela n'a aucun sens.
on supprime toutes les addr des villes oü tu ne vas pas ?
elle sont dispo en opendata après tout.
c'est déjà parfois difficile de se comprendre sans 2ieme ou 3ieme degré,
alors évitons les :)

Le 15.03.19 à 16:29, Léo El Amri via Talk-fr a écrit :
> catégoriser les découpages

je pense que la majorité existent déjà.

Par exemple pour le quartier de Paris,
le populaire (celui avec un place=*) ayant une limite
que personne ne semble contester, il peux facilement
être tagé comme une aire : c'est la seule façon de transformer
l'étendue bleue de l'image précédente en donnée osm.

sinon on arrive à un résultat incohérent : on dit que le quartier 
populaire mérite d'être ajouté dans osm car différent du découpage 
administratif du même nom, mais l'ajout dans osm ne montre pas cette 
différence et mettre une note sur les 2 objets ne permet pas plus
"d'utiliser" cette différence.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] adressage dans les zones sans nom de voie - exemple un aérodrome

[marc marc]

de l'exemple de ton ticket, par ex
https://www.openstreetmap.org/node/6332817525
je pense qu'il est + correcte de changer
addr:street="Résidence l'Orée de Marly" en addr:place
et mettre un place=neighbourhood name=Résidence l'Orée de Marly.
Dans certains autres cas place=city_block peux être + adapté.

Le 15.03.19 à 16:19, Jérôme Seigneuret a écrit :
> ok c'est fait
> 
> Le ven. 15 mars 2019 à 14:16, Vincent de Château-Thierry 
> mailto:osm.v...@free.fr>> a écrit :
> 
> 
>  > De: "Jérôme Seigneuret"  >
>  >
>  > PS hors optique Lieudit tu as le même problème sur les gros complexes
>  > résidentielle avec numéro voir numéro + Lettre, Numéro plus nom de
>  > batiment et sans pour autant avoir un nm de rue. En région
>  > parisienne je suis confronté régulièrement à ce problème. Certains
>  > on patché ça en mettant le nom de la résidence sur la voirie et fait
>  > de même sur les numéros d'adresse. Ducoup il y a pas mal de nom de
>  > voie dans BANO avec lotissement * ou résidence * qui n'ont pas de
>  > réelle existance.
>  >
>  > As tu pris ça en compte dans la V2?
> 
> Je n'ai pas touché aux logiques métier dans la v2, c'est surtout une
> version qui permet de mieux coller aux versions courantes de Fantoir
> et Cadastre durablement, en profitant des publications sur
> data.gouv.fr . Donc je ne pense pas que ça soit
> plus géré qu'avant, mais je veux bien les exemples dont tu parles
> histoire d'appréhender le sujet concrètement. Tu peux en indiquer
> ici, ou directement créer un ticket =>
> https://github.com/osm-fr/bano/issues/new
> 
> merci
> vincent
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> -- 
> Cordialement,
> Jérôme Seigneuret
> 
> ___
> 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: [Talk-ca] Building Import

[Danny McDonald]

OK, so this discussion has gone a bit off the rails.  In terms of the DWG,
this has all happened so fast - the referral to the DWG was less than 2
hours after the initial message, and was not in response to any actual
edits I made after receiving Pierre's stop message.

I suggest that we all stop emailing this list for the rest of the day,
given the high level of tension on both sides.  I will not be importing
anything for the next week (at the very least), and I don't think anyone
else will either.
DannyMcD
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[OSM-talk-fr] Création de communes nouvelles

[Donat ROBAUX]

Bonjour,

Un arrêté du 8 mars 2019 porte création de 20 communes nouvelles au 1er
janvier 2019.
https://www.service-public.fr/particuliers/actualites/A13282

Je crois qu'on aura pas fait pire dans le WTF administratif. Les arrêtés
préfectoraux ont bien été pris en 2018 pour un démarrage au 1er janvier et
donc intégrés dans OSM par Christian avec sa moulinette. Mais la
publication au JO date du 8 mars!
Je n'ai pas regardé si elles y étaient toutes.

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

Re: [OSM-talk-fr] [vélo] Introduction d'un tag complexe pour décrire les DSC sur bande dans le wiki

[Phyks]

Salut,

> En tant que structuraliste opposite_* est intolérable.

Il y a un certain nombre de cas comme ça d'ailleurs sur les attributs
vélos. J'ai en tête par exemple aussi le `bicycle_parking` dont la
variante `motorcycle_parking` n'existe pas. On se retrouve donc avec des
`amenity=motorcycle_parking` et `bicycle_parking=stands` qui ne sont
absolument pas ouverts ou prévus pour des vélos.


> Dans tous les cas, aujourd'hui je ne ressens aucun besoin de changer le
> schéma opposite_*

Idem, je vois un petit intérêt à utiliser l'alternative avec
`cycleway:*:oneway`, mais cela ne vaut probablement pas de casser tout
l'écosystème basé sur le schéma actuel à mon avis (déjà que tous les
outils ne supportent pas les cycleway:left/right proprement…).



Il y avait récemment eu une discussion sur des différences entre la
version anglaise et française de la page "Bicycle" du wiki il me semble
(sur talk-fr, sur un autre cas, mais je ne le retrouve plus :/).

-- 
Phyks


> Le mer. 13 mars 2019 à 22:11, Charles MILLET  a
> écrit :
> 
>> Dans l'absolu sa proposition tient la route. C'est juste que c'est un peu
>> lourd et que dans la pratique le opposite_lane est bien utilisé et
>> parfaitement interprétable.
>>
>> Et comme le dis marc c'est pas la bonne pratique, même quand on est
>> convaincu qu'on a raison... parce qu'on est nombreux à être convaincu
>> d'avoir raison :D
>>
>> J'avais vu ta position sur la distinction entre le sens et l'infra et
>> effectivement vous tombé plutôt d'accord. J'avais la même position il y a
>> quelques années... et puis j'ai laissé tombé :) et en fait j'ai admis que
>> la clé cycleway c'est qu'une clé et du moment qu'on est d'accord sur ce que
>> signifient les tags qui l'utilisent et bien on peut renoncer un peu à cette
>> logique. Donc vois si tu veux rester sur cette position mais dis toi que si
>> elle n'est pas adoptée ça n'aura pas trop d'influence... on en reparle
>> peut-être de vive voix bientôt ? ;)
>>
>> Pour l'instant j'essaie de prendre un peu le pouls sur cette approche du
>> DSC puisque les calculateurs ne l'utilisent pas je pense alors que les
>> cycleway:left/right=opposite_* sont plutôt admis (il me semble qu'au moins
>> BRouter et Geovelo les prennent en compte mais je pense que d'autres le
>> font).
>> On 13/03/2019 21:14, Florimond Berthoux wrote:
>>
>> Bonsoir,
>>
>> Et par ici aussi
>> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Acycleway%3Dopposite_lane=revision=1820887=1639352
>> mais pas ici
>> https://wiki.openstreetmap.org/wiki/Key:cycleway#Dedicated_cycle_lanes
>> Je trouve la communauté particulièrement coulante vis-à-vis de ce genre de
>> modification unipersonnelle.
>>
>> Après je comprend tout à fait son point de vue : la signification d'un tag
>> devrait être la plus simple possible et ne pas comporter deux
>> significations comme avec opposite_lane (sens et infrastructure).
>>
>>
>> Le mer. 13 mars 2019 à 15:04, Charles MILLET  a
>> écrit :
>>
>>> Bonjour à tous
>>>
>>> Un contributeur a mis à jour la page wiki concernant la manière de
>>> décrire les doubles sens cyclables sur bande :
>>>
>>>
>>> https://wiki.openstreetmap.org/w/index.php?title=FR:Bicycle=next=1780997
>>>
>>> Pour résumer, il a supprimé les cycleway:left/richt=opposite_lane car
>>> cette valeur n'est pas documentée dans les valeurs des clé
>>> cycleway:left/richt (même si elle l'est pour la clé cycleway)
>>>
>>> Il recommande donc :
>>>
>>> highway=* + oneway=yes + cycleway:left=lane + cycleway:left:oneway=-1
>>>
>>> plutôt que
>>>
>>> highway=* + oneway=yes + cycleway:left=opposite_lane
>>>
>>> :'(
>>>
>>> Je lui ai envoyé un message pour lui exprimé avec politesse que je pense
>>> qu'il vaudrait mieux admettre ou officialiser
>>> cycleway:left=opposite_lane mais je m'attend que ce type de contribution
>>> traduise une volonté de respecter rigoureusement le wiki...
>>>
>>> Je m'adresse à la liste pour avoir votre avis au regard de l'usage qu'on
>>> peut observer sur taginfo et quelle serait la démarche pour revoir cette
>>> modification et dans l'idéal valider dans les règles les tags
>>> cycleway:left/right=opposite_lane
>>>
>>> Bonne journée
>>>
>>> Charles
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>> --
>> Florimond Berthoux
>>
>> ___
>> Talk-fr mailing 
>> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
> 
> 
> -- 
> Florimond Berthoux
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 



___
Talk-fr mailing list
Talk-fr@openstreetmap.org

Re: [Talk-ca] Building Import

[Martin Chalifoux via Talk-ca]

I certainly agree with that statement ! Importing should be much more rigorous 
and careful, as mistakes or poor execution is costly. 

> On Mar 15, 2019, at 11:29, Nate Wessel  wrote:
> 
> There is a massive difference between making edits without review and 
> importing millions of buildings without review. 
> 
> 

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

Re: [OSM-talk-fr] Quartiers à Paris

[Léo El Amri via Talk-fr]

On 15/03/2019 15:46, Vincent de Château-Thierry wrote:
> En élargissant, je pense que tous les découpages ont leur place dans OSM : 
> administratifs, religieux, militaires, académiques et j'en passe, dès lors 
> qu'on dispose d'une source précise et compatible pour leur délimitation. Ils 
> sont une formidable porte d'entrée pour nombre de consommateurs des données 
> OSM, notamment pour de la cartographie statistique, mais sûrement pas que. 
> Alors évitons de données des idées contre-productives en suggérant la 
> dégradation voire la suppression de certains d'entre eux.

Je suis tout à fait d'accord, et je trouve que ça réconcilie par mal
d'avis "contraires" qui ont été évoqués au sujet de la délimitation des
quartiers (De Paris et d'ailleurs) et des bordures de la Bretagne sur
cette mailing-list.

Nous ne devrions pas élire et se reposer sur un seul découpage. Et on
peut se permettre de créer des tags pour catégoriser les découpages pour
OSM en France (À implémenter, voter et documenter dans ce cas).

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

Re: [Talk-ca] Building Import

[Nate Wessel]

Seriously Danny?

Pierre was the first to suggest the DWG after you replied to him that 
wouldn't engage in further discussion. You only joined this conversation 
after I reported you.


There is a massive difference between making edits without review and 
importing millions of buildings without review.


Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 3/15/19 11:23 AM, Danny McDonald wrote:
By the way, I strongly object to the way Nate immediately went to the 
DWG, instead of attempting to engage in discussion.


I think many people on this list fundamentally misunderstand the way 
OSM operates.  Most OSM contributions are made by individuals who see 
a gap/mistake in the data and fix it.  It is not a "community process" 
where contributions are made by a group of "local mappers" (although 
this sometimes happens).


The great strength of OSM (relative to Google Maps), is that you can 
make edits immediately without going through a peer review process.  
Some people on this list seem to want to impose a peer review process 
on OSM (at least for imports, for now), because they think they know 
better, and should be given power because of it.


DannyMcD

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

[Talk-ca] Building Import

[Danny McDonald]

By the way, I strongly object to the way Nate immediately went to the DWG,
instead of attempting to engage in discussion.

I think many people on this list fundamentally misunderstand the way OSM
operates.  Most OSM contributions are made by individuals who see a
gap/mistake in the data and fix it.  It is not a "community process" where
contributions are made by a group of "local mappers" (although this
sometimes happens).

The great strength of OSM (relative to Google Maps), is that you can make
edits immediately without going through a peer review process.  Some people
on this list seem to want to impose a peer review process on OSM (at least
for imports, for now), because they think they know better, and should be
given power because of it.

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

Re: [Talk-ca] Building import in BC and Quebec

[Yaro Shkvorets]

As an experienced local Ontario and Quebec mapper I don't see any major
problems with Stats Can building quality. It's detailed and recent, it's
the best dataset we could ever possibly get and it's far superior to
Microsoft quality. Having many buildings with "almost square angles" in
this dataset is not an issue as vast majority of such deviations cannot be
seen with a naked eye. Unfortunately any orthogonalization algorithms will
do more harm than good in such cases. Mapping for the Validator, just like
mapping for the Renderer is a wrong way to map.
Issues were raised, issues were addressed in the import plan. If there are
any problems with some mappers violating any specific import plan rules
such issues need to be pointed out so they can adjust their workflow.
My 2 cents.

On Fri, Mar 15, 2019 at 10:55 AM Nate Wessel  wrote:

> I just reported this to the data working group, in case you haven't
> already. Hopefully they will step in!
>
> Cheers,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 3/15/19 10:30 AM, Pierre Béland wrote:
>
> Réponse immédiate avec refus de discussion de la part de DannyMcD_imports.
> Celui-ci indique qu'il prévoit continuer l'import.
> voir https://www.openstreetmap.org/changeset/67686901
>
> There was a discussion, issues were raised, the problems (to the extent
> that they existed at all) have been addressed. I plan to continue
> importing, unless a *specific* valid issue is raised. Please do not contact
> me again unless you have such an issue.
>
> La prochaine étape est je pense de contacter le Data Working Group.
>
>
> Pierre
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>


-- 
Best Regards,
  Yaro Shkvorets
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-fr] adressage dans les zones sans nom de voie - exemple un aérodrome

[Jérôme Seigneuret]

ok c'est fait

Le ven. 15 mars 2019 à 14:16, Vincent de Château-Thierry 
a écrit :

>
> > De: "Jérôme Seigneuret" 
> >
> > PS hors optique Lieudit tu as le même problème sur les gros complexes
> > résidentielle avec numéro voir numéro + Lettre, Numéro plus nom de
> > batiment et sans pour autant avoir un nm de rue. En région
> > parisienne je suis confronté régulièrement à ce problème. Certains
> > on patché ça en mettant le nom de la résidence sur la voirie et fait
> > de même sur les numéros d'adresse. Ducoup il y a pas mal de nom de
> > voie dans BANO avec lotissement * ou résidence * qui n'ont pas de
> > réelle existance.
> >
> > As tu pris ça en compte dans la V2?
>
> Je n'ai pas touché aux logiques métier dans la v2, c'est surtout une
> version qui permet de mieux coller aux versions courantes de Fantoir et
> Cadastre durablement, en profitant des publications sur data.gouv.fr.
> Donc je ne pense pas que ça soit plus géré qu'avant, mais je veux bien les
> exemples dont tu parles histoire d'appréhender le sujet concrètement. Tu
> peux en indiquer ici, ou directement créer un ticket =>
> https://github.com/osm-fr/bano/issues/new
>
> merci
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-ca] Building Import

[Danny McDonald]

As previously noted, I will continue importing, unless I hear a specific
valid concern.  I will wait a week before re-starting, to allow time for
concerns to be raised.  To address some existing concerns:
- Making buildings orthogonal isn't an improvement, it is degrading correct
footprints for no good reason.
- I don't think mapping a large block of connected buildings as a single
building is incorrect.  It might be better to split large blocks of
buildings, but this is best done separately from the initial import.

As for local mappers, PierZen is a Quebec mapper, and Nate seems to map
almost exclusively around Cincinnati - I don't think either qualify as a
local mapper for Toronto or BC.
DannyMcD
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building import in BC and Quebec

[Nate Wessel]

I just reported this to the data working group, in case you haven't 
already. Hopefully they will step in!


Cheers,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 3/15/19 10:30 AM, Pierre Béland wrote:
Réponse immédiate avec refus de discussion de la part de 
DannyMcD_imports. Celui-ci indique qu'il prévoit continuer l'import.

voir https://www.openstreetmap.org/changeset/67686901

There was a discussion, issues were raised, the problems (to the 
extent that they existed at all) have been addressed. I plan to 
continue importing, unless a *specific* valid issue is raised. Please 
do not contact me again unless you have such an issue.



La prochaine étape est je pense de contacter le Data Working Group.


Pierre


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

Re: [OSM-talk] Maproulette

[Martijn van Exel]

> On Mar 15, 2019, at 8:30 AM, Mateusz Konieczny  
> wrote:
...
> I was rather interested in checking whatever there is any place in world with 
> more
> mappers than task.
> I created Maproulette task long time ago and noone was solving it, one of 
> reasons was
> that it was in places flooded anyway with Maproulette tasks and without any 
> active users.

The original premise of MapRoulette was that it doesn’t matter where you are, 
you can solve any task from anywhere. This is still true today[1], so if there 
is a challenge that doesn’t get solved there may be another reason for it. I 
can always feature it for you if you want, then it appears at the top of the 
list and on the landing page.

Martijn

[1] However, with mobile support coming, there will be opportunities to support 
tasks that require on the ground survey. Once we get there, challenges that 
require eyes on the ground would be tagged as such. Current users of the 
MapRoulette API such as Vespucci could use that to filter tasks.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] pic4review | Re: 140 000 shops of unspecified type

[PanierAvide]

Hello,

Great to see Pic4Review being used :-) Note that missions can be 
configured with ready-to-use answers, mission creator set the possible 
answers (one per shop=* value, picture/symbol can be associated) so that 
contributors don't need to write shop value themselves when reviewing. 
This can take few minutes to configure for mission creator, but make 
task really easier / faster for contributors. I can provide some help if 
needed.


Regards,

Adrien P.

Le 15/03/2019 à 12:52, Rory McCann a écrit :

On 15/03/2019 11:08, Mateusz Konieczny wrote:

how to find it?

JOSM validator since latest released version complains about shop=yes -
just download data and run validator

Osmose has support for displaying JOSM validator complaints
http://osmose.openstreetmap.fr/en/map/#item=9002=1%2C2%2C3== 


shows JOSM deprecation warnings

http://overpass-turbo.eu/s/H0S - you can navigate to your area and 
press run


pic4review ( https://pic4review.pavie.info/ ) is a new editor which 
uses Mapillary & OpenStreetCam to make targetted edits to OSM objects. 
I've been exploring it for changing shop=yes tags and it's pretty useful.


This is for Dublin, but you can duplicate it elsewhere 
https://pic4review.pavie.info/#/mission/417


With street level imagery like that, remote mapping is much more 
reliable.


___
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] Quartiers à Paris

[Vincent de Château-Thierry]

> De: "althio" 
> 
> Et si quelqu'un veut renommer le quartier administratif de la
> Goutte-d'Or en :
> name=Quartier administratif de la Goutte-d'Or
> ou name=71e quartier administratif
> ou name=administratif_police_7511871
> Franchement... ça ne me dérange pas, ce truc n'a aucune existence de
> terrain.

> Et si quelqu'un veut supprimer le quartier administratif parce que
> [insérer ici une raison quelconque]... je dis "pourquoi pas", de
> toute façon c'est de la donnée de référence, on la retrouve en open
> data.

Donc le fait qu'une donnée n'aie "aucune existence de terrain" et/ou se 
"retrouve en open data" serait une raison suffisante pour la saccager dans OSM 
: renommage inconsidéré, suppression... Avec une logique pareille, j'ai peur 
pour la préservation des limites administratives (communales mais pas que, 
après tout) dans OSM. C'est vrai : aucune existence de terrain, et dispo en 
open data.

Est-ce qu'on peut arrêter ces divagations ?

Les limites administratives sont une des pépites d'OSM en France : une couche 
complète depuis fin 2013, un vrai travail collaboratif, une donnée à jour avant 
toutes les données concurrentes grâce à la maintenance impulsée à chaque fin 
d'année civile pour appréhender les fusions de communes et autres mouvements. 
Bref, une vraie valeur ajoutée dont on devrait être collectivement fiers.

En élargissant, je pense que tous les découpages ont leur place dans OSM : 
administratifs, religieux, militaires, académiques et j'en passe, dès lors 
qu'on dispose d'une source précise et compatible pour leur délimitation. Ils 
sont une formidable porte d'entrée pour nombre de consommateurs des données 
OSM, notamment pour de la cartographie statistique, mais sûrement pas que. 
Alors évitons de données des idées contre-productives en suggérant la 
dégradation voire la suppression de certains d'entre eux.

Plus généralement, je voudrais insister sur un point pas assez souvent rappelé 
: ça n'est pas parce qu'à titre individuel on n'a pas connaissance de la 
réutilisation d'une donnée que celle-ci n'est pas utile à d'autres. Le 
périmètre "rendu Mapnik / OSMAnd / OSRM / Geovelo" (pour faire un peu court) 
est loin de représenter tout ce qui peut bien se fabriquer à partir de données 
OSM. Ne réduisons pas les réutilisations possibles, potentielles, aux seules 
réutilisations connues, populaires. Notre méconnaissance de ce que font 
certains avec les données que nous produisons devrait nous inciter à la 
prudence et à la modération, pas aux suggestions bravaches de modifications 
inconsidérées.

merci
vincent

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

Re: [Talk-it] [talk-it]

[Martin Koppenhoefer]

Am Fr., 15. März 2019 um 15:39 Uhr schrieb Volker Schmidt :

> O detto in altre parole:
> se convertissi tutti i negozi in Italia che vendono bicicli di entrambi
> tipi a questo tagging doppio, forse sarebbe un metodo per forzare i
> renderer di prenderne atto?
>


se lo facessi al livello mondiale sicuramente :)

Ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [talk-it]

[Volker Schmidt]

Non è la soluzione.
In Italia, e probabilmente in tanti altri paesi, c'è una diffusa e vecchia
tradizione che lo stesso negozio vende bicicli motorizzati e
non-motorizzati. A me interessa che lo stesso negozio sia riconosciuto a
pieno diritto da data consumers come shop=motorcycle *e* shop=bicycle.
So che tocco una limitazione fondamentale della prassi di OSM (non di OSM
stesso, perché c'è la posibilità di utilizzare shop=bicycle;motorcycle). E
non è l'unico caso.
O detto in altre parole:
se convertissi tutti i negozi in Italia che vendono bicicli di entrambi
tipi a questo tagging doppio, forse sarebbe un metodo per forzare i
renderer di prenderne atto?

Volker

On Fri, 15 Mar 2019 at 15:28, liste DOT girarsi AT posteo DOT eu <
liste.gira...@posteo.eu> wrote:

> Il 15/03/19 09:13, Volker Schmidt ha scritto:
> > La domand più vecchia del mondo:
> >
> > com taggare un negozio che vende bici e motocicl?
> > Ci ne devono essere migliaia in Italia.
> > shop=bicycle;motorcyle ?
> > Ne trovo solo una manciata in Taginfo.
> > Allora non va bene.
> > Ma che cosa metto? Due nodi sovrapposti con tutto identico, salvo shop= ?
> >
>
> Direi se possibile valutare l'attività prevalente, e metterla come shop,
> in aggiunta l'attività secondaria come sells:attivitasecondaria=yes.
>
> E se vende anche parti di ricambio per entrambi, in questo caso non c'è
> problema perchè si può specificare per singolo tag come nelle pagine
> dedicate sulla wiki.
>
>
>
> --
> _|_|_|_|_|_|_|_|_|_
> |_|_|_|_|_|_|_|_|_|_|
> Simone Girardelli
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-ca] Building import in BC and Quebec

[Nate Wessel]

Given the scale of this illicit import (thanks Pierre for the stats!), I 
would, yes, stick my neck out and say that I oppose this action as a 
Canadian mapper. Contributors who are clearly violating community norms 
about discussion and consensus do not constitute an implicit consensus 
of some local community. In the absence of a healthy local discussion 
about this, I think it's up to us to say that this needs to stop.


The tasking manager for this project should be taken down immediately. 
Whether they strictly need it to continue or not, they are (ab)using it 
and it's clearly helping them continue with an import that is being 
actively disputed.


Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 3/15/19 8:28 AM, Jarek Piórkowski wrote:

IMO the huron/hamptonavemapper import is quite clearly in active
disagreement with the import suspension - while I could believe that
one user could overlook clicking on the wiki link in their changeset
messages just once and seeing the bold "on hold", setting up a brand
new similarly named account on February 15, 2019 and immediately
starting to import suggests they know what they're doing. And it's not
like one ultimately _needs_ the tasking manager to insert the data.

The question is what are we going to do about it? Are you going to
speak for Alberta and BC in opposing this import, Nate? That's
defensible but also debatable.

--Jarek

On Thu, 14 Mar 2019 at 21:12, Nate Wessel  wrote:

I would suggest, again, that the tasking manager for this import be locked or 
taken down if that is not possible. One good way to stop people from importing 
when we don't have consensus is to not make it so easy for them. Indeed, I 
would find it plausible if these people said they didn't even know the import 
was paused - their evidence: that the tasking manager is still active!

Best,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com

On 3/14/19 7:42 PM, Jarek Piórkowski wrote:

The changeset comment messages link to the Stats Canada import plan on
the OSM wiki.

I missed it but there were also some edits in Alberta. Quebec edits I
saw were only a couple, outside of Quebec.

http://tasks.osmcanada.ca/project/148 has also been updated, and the
Alberta tasks.

It does raise the point that with a country this large, with editor
community this sparse, there are very few ways to enforce or police a
countrywide consensus, or even arrive at one. Maybe BC mappers like
the import, square angles or no? (Does anyone go to the Metrotown
Meetup?)

--Jarek

On Thu, 14 Mar 2019 at 19:36, john whelan  wrote:

Wicked lad importing without an import plan?

Ask him nicely where the import plan for their imports is.

Looks like a new mapper so may not know the rules.

I think currently there are two sets of data that are licensed for import, the 
Stats Can stuff and the Microsoft stuff.  I haven't seen any import plan for 
the Microsoft stuff but unfortunately it's probably fairly easy to import on 
the Stats Can side my feeling is we need to work out who the locals are to get 
buy in since Canada wide there is no consensus on what is acceptable.  After a 
request from a local group then I think that particular area can proceed.

Quebec I think is being organised by Tim.

Thanks John

On Thu, 14 Mar 2019 at 18:56, Jarek Piórkowski  wrote:

Are people aware that there are buildings being imported by
https://www.openstreetmap.org/user/huronavemapper (most recent 12
hours ago) and https://www.openstreetmap.org/user/hamptonavemapper
(most recent 5 days ago)?

I notice the wiki still says the import is on hold.

Thanks,
--Jarek

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

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

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

Re: [Talk-ca] Building import in BC and Quebec

[Pierre Béland via Talk-ca]

Réponse immédiate avec refus de discussion de la part de DannyMcD_imports. 
Celui-ci indique qu'il prévoit continuer l'import.voir 
https://www.openstreetmap.org/changeset/67686901
| 
There was a discussion, issues were raised, the problems (to the extent that 
they existed at all) have been addressed. I plan to continue importing, unless 
a *specific* valid issue is raised. Please do not contact me again unless you 
have such an issue.
 |


La prochaine étape est je pense de contacter le Data Working Group.
 
Pierre 
 

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

Re: [OSM-talk] Maproulette

[Mateusz Konieczny]

Mar 15, 2019, 3:25 PM by m...@rtijn.org:

>
>
>> On Mar 15, 2019, at 4:39 AM, Mateusz Konieczny <>> matkoni...@tutanota.com 
>> >> > wrote:
>>
> ...
>
>>
>> Are you aware about any location across the world that suffers from
>> lack of tasks in Maproulette for mappers?
>>
>> I would create something there (though not for shop=yes, it often requires 
>> survey).
>>
> There are a few ways in which mappers can narrow down to ‘local’ tasks.
>
I was rather interested in checking whatever there is any place in world with 
more
mappers than task.

I created Maproulette task long time ago and noone was solving it, one of 
reasons was
that it was in places flooded anyway with Maproulette tasks and without any 
active users.

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

Re: [Talk-it] [talk-it]

[liste DOT girarsi AT posteo DOT eu]

Il 15/03/19 09:13, Volker Schmidt ha scritto:
> La domand più vecchia del mondo:
> 
> com taggare un negozio che vende bici e motocicl?
> Ci ne devono essere migliaia in Italia.
> shop=bicycle;motorcyle ?
> Ne trovo solo una manciata in Taginfo.
> Allora non va bene.
> Ma che cosa metto? Due nodi sovrapposti con tutto identico, salvo shop= ?
> 

Direi se possibile valutare l'attività prevalente, e metterla come shop,
in aggiunta l'attività secondaria come sells:attivitasecondaria=yes.

E se vende anche parti di ricambio per entrambi, in questo caso non c'è
problema perchè si può specificare per singolo tag come nelle pagine
dedicate sulla wiki.



-- 
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [OSM-talk] Maproulette

[Martijn van Exel]

> On Mar 15, 2019, at 4:39 AM, Mateusz Konieczny  
> wrote:
...
> 
> Are you aware about any location across the world that suffers from
> lack of tasks in Maproulette for mappers?
> 
> I would create something there (though not for shop=yes, it often requires 
> survey).

You can create a global challenge if you want, but 140,000 may be stretching it 
a bit on the server. You’re welcome to try though.
There are a few ways in which mappers can narrow down to ‘local’ tasks.
1) when you zoom in far enough on the main map you will see all tasks in the 
area and you can create a ‘virtual’ challenge with just those tasks
2) You can opt to work on tasks based on proximity to the current task. This 
will prevent you from ‘jumping’ randomly around the world
3) Soon, MapRoulette will also support mobile devices natively
4) If you’re a developer or technically inclined, you can use the MapRoulette 
API to retrieve tasks selectively, 
https://maproulette.org/docs/swagger-ui/index.html 
 you’re welcome to use this 
in any app or other web site.

Martijn

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

Re: [OSM-talk-fr] Tuiles cadatsre sans réponse sur JOSM

[Jozeph via Talk-fr]

Bonjour,

Oui je rencontre ce problème depuis hier avec le message :

"Erreur lors du chargement des tuiles :
javax.net.ssl.SSLProtocolException handshake alert: unrecognized_name"

Je ne sais pas introduire le paramètre supplémentaire dans le lancement de JOSM 
comme indiqué par Denis.

Que me conseillez-vous ?

Avec mes remerciements.

Joseph

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

Re: [Talk-it] name, operator e official_name

[Martin Koppenhoefer]

sent from a phone

> On 15. Mar 2019, at 14:50, Federico Cortese  wrote:
> 
>> On Fri, Mar 15, 2019 at 2:44 PM demon_box  wrote:
>> 
>> name="Officina Meccanica Fratelli Ronchini"
>> operator="Officina Meccanica Fratelli Ronchini Sergio, Roberto e Ezio
>> S.n.c."
> Secondo me va bene così.
> 
>> name="Gelateria Pinguino"
>> operator="Rossi Mario S.r.l." oppure anche in questo caso
>> operator="Gelateria Pinguino di Rossi Mario S.r.l."?
>> 
> 
> In questo caso direi la seconda.
> Se hai la partita IVA puoi anche verificare la denominazione ufficiale su:
> https://telematici.agenziaentrate.gov.it/VerificaPIVA/Scegli.do?parameter=verificaPiva


+1 a tutto (operator  dovrebbe essere il nome ufficiale del gestore, se 
esiste). Mentre sarebbe l’ ideale verificare il nome registrato in un db 
esterno, non è una necessità. Meglio inserire i dati “best guess” che non 
mettere niente. 
Piccola promemoria, il tag per la partita iva è
ref:vatin=IT123456...

Ciao, Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-ca] Building import in BC and Quebec

[Pierre Béland via Talk-ca]

Bonjour Jarek
Ce n'est malheureusement pas le seul contributeur qui agit ainsi.  J'estime en 
divisant (Objets/5) que depuis le 1er février, 6 contributeurs ont importé près 
de 1 million de bâtiments. Selon les commentaires, 5 provinces ont été 
couvertes. Cette information est parfois inexacte. Un fichier json des bbox de 
chaque changeset nous fournirait une information plus précise.Voir par exemple 
https://www.openstreetmap.org/changeset/67725913 
J'ai joint ci-dessous un tableau sommaire et la liste des changesets par 
contributeur.

Nous faisons face à un import massif. Ce ne sont pas des débutants qui font ces 
imports et ces contributeurs doivent justifier leurs actions depuis le début 
février et expliquer la méthode suivie pour corriger les données. 
Je viens juste d'aviser chacun de ces contributeurs de cesser les imports et 
venir en discuter sur la liste.
https://www.openstreetmap.org/changeset/67725913
https://www.openstreetmap.org/changeset/68043362
https://www.openstreetmap.org/changeset/68112880
https://www.openstreetmap.org/changeset/67956418
https://www.openstreetmap.org/changeset/67686901
https://www.openstreetmap.org/changeset/68131003

    Imports Statcan depuis le 1er février - Nombre d'objets par 
province

| 
 | OSM Uiid | 
 | 
 | 
 | 
 | 
 | 
 |
| Province | 215433 | 1919010 | 5214232 | 5323321 | 9266764 | 9444677 | Total |
| Alberta | 152 033 | 
 | 
 | 474 276 | 
 | 586 403 | 1 212 712 |
| BC | 44 115 | 
 | 
 | 1 833 617 | 
 | 506 552 | 2 384 284 |
| New Brunswick | 389 750 | 
 | 
 | 
 | 
 | 
 | 389 750 |
| Ontario | 
 | 2 758 | 
 | 
 | 470 608 | 
 | 473 366 |
| Québec | 297 444 | 
 | 110 484 | 753 | 
 | 
 | 408 681 |
| Total | 883 342 | 2 758 | 110 484 | 2 308 646 | 470 608 | 1 092 955 | 4 868 
793 |


Liste des changesets par contributeurUid 215433 Alberta 67665215, 67665288, 
67665341, 67665453, 67665483, 67665545, 67665602, 67665808, 67665875, 67666001, 
67666180, 67669204, 67669252, 67669308, 67669354, 67669452, 67669522, 67669613, 
67670220, 67670247, 67670273, 67670311, 67670349, 67670387, 67670421, 67670458, 
67670536, 67670908, 67670939BC 67508204, 67508256, 67508291, 67508458, 
67508490, 67508513, 67508622, 67508649, 67508697New Brunswick 67507944, 
67508112, 67508134, 67530245, 67530288, 67530337, 67530387, 67530430, 67530474, 
67530523, 67530791, 67530835, 67531044, 67531220, 67531330, 67531597, 67531938, 
67532009, 67532116, 67532730, 67532743, 67569125, 67569223, 67569803, 67569881, 
67569899, 67569919, 67569960, 67602916, 67603189, 67603261, 67603269, 67603307, 
67603335, 67603367, 67603432, 67603554, 67603678, 67603804, 67604023, 67604270, 
67604320, 6779, 67700103, 67700186, 67700343, 67701266, 67701566, 67704840, 
67704865, 67704907, 67705047, 67705069, 67705120, 67705156, 67705204, 67705284, 
67705553, 67705562, 67705602, 67705662, 67705703, 67705762, 67705815, 67705920, 
67705931, 67706273, 67706329, 67706346, 67706464, 67706503, 67706521, 67719310, 
67719682, 67720148, 67720387, 67720605, 67720722, 67720888, 67720980, 67721152, 
67721270, 67723337, 67724221, 67724317, 67724413, 67724441, 67724618, 67724667, 
67724722, 67724746, 67724785, 67724876, 67724959, 67725077, 67725194, 67725830, 
67725849, 67725878, 67725913, 67725961, 67787993Québec 67498534, 67498609, 
67498689, 67498757, 67498912, 67505394, 67505479, 67505545, 67505558, 67505578, 
67505614, 67505972, 67506005, 67506059, 67506089, 67506346, 67506485, 67506686, 
67506719, 67506875, 67506907, 67506934, 67506947, 67506976, 67507006, 67507027, 
67507041, 67507049, 67507068, 67507105, 67507117, 67507136, 67507160, 67507175, 
67507185, 67507195, 67507202, 67507216, 67507260, 67507285, 67507297, 67507312, 
67507320, 67507331, 67507344, 67507355, 67507356, 67507363, 67520439, 67520589, 
67521376, 67521445, 67521517, 67522086, 67522182, 67523774, 67523861, 67523987, 
67524091, 67524121, 67524132, 67524260, 67524661, 67524728, 67524805, 67525070, 
67525203, 67525335, 67525528, 67526340, 67526436, 67526514, 67526916, 67527123, 
67527293, 67527489, 67527970, 67528040, 67528316, 67528511, 67528581, 67528645, 
67528686, 67528728, 67528787, 67528860, 67528901, 67528967, 67529024, 67529042, 
67529077, 67529173, 67529225, 67529262, 67529307, 67529347, 67529374, 67529413
Uid 1919010 Ontario 68042707, 68042895, 68043362, 68043390, 68043779, 68043921, 
68044088
Uid 5214232 Québec 67957273, 67957348, 67957729, 67958923, 67959011, 67986700, 
67986777, 68069537, 68069649, 68078450, 68078523, 68112014, 68112112, 
68112880Uid 5323321 Alberta 66858409, 66858508, 66858697, 66931104, 66931208, 
66931808, 66932459, 66937105, 66944951, 66945388, 66945814, 66945894, 66946017, 
66946173, 66946358, 66960875, 66961117, 66961283, 66961447, 66962026, 66962184, 
66963495, 66963589, 67022393, 67033345, 67033434, 67033507, 67037604, 67037672, 
67037926, 67038133, 67046475, 67046558, 67046687, 67047191, 67047267, 67047343, 
67047419, 67048115, 67048188, 67048931, 67048997, 67049058, 67049627, 67050230, 
67050277, 

Re: [OSM-talk-fr] Calcul d'itinéraire avec OSRM - questionnement calcul

[Rpnpif]

Le 14 mars 2019, Violaine_Do a écrit :

> Bonjour tout le monde,
> 
> Je me demandais comment améliorer le calcul d'itinéraire, avec OSRM (sur 
> osm.org) en fonction de conditions locales (cf profil voiture utilisé 
> sur OSM.org 1)
> 
> Pour le moment primary, secondary et tertiary ne montent par défaut pas 
> a plus de 65km/h, les exceptions rurales sont souvent au dessus.. (cf 
> wiki speed limits : 2, par exemple pour les routes rurales en france on 
> a comme tag maxspeed=80 + source:maxspeed=FR:rural) Donc avec maxspeed 
> on dépasse la vitesse par défaut du type de route tertiary, secondary, 
> primary. Mais pour avoir fait un petit test, je comprends pas le calcul, 
> par exemple avec un tronçon en particulier (3) : je ne trouve pas la 
> vitesse attendue (j'aimerais que le calcul prenne en compte la vitesse 
> rurale c'est à dire 80km/h plutôt que la vitesse du type de route 
> secondary qui est à 55km/h, information qui est présente sur ce 
> tronçon). Est-ce que c'est parce que primary/secondary/tertiary sont 
> prioritaires/contraignent le reste? (en gros faudrait il changer les 
> vitesses par defaut primary/secondary/tertiary pour permettre 
> l'utilisation des maxspeed?). J'espère que je suis assez compréhensible...

Sur une route à 80 km/h, on ne roule pas à 80 km/h en moyenne sauf si
on dépasse la vitesse légale, à cause des décélérations, etc. C'est
peut-être pourquoi la vitesse est calculée en dessous, peut-être 5 à 20% en 
dessous.

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] Quartiers à Paris

[althio]

> En représentation cela donne ceci aujourd'hui
https://overpass-turbo.eu/s/GZD

Je trouve cette représentation utile et la richesse des données géniale.
Elle me donne envie de vérifier ou d'ajouter d'autres quartiers, mais pas
d'en supprimer.
Je ne vois aucun doublon.

Et si quelqu'un veut renommer le quartier administratif de la Goutte-d'Or
en :
name=Quartier administratif de la Goutte-d'Or
ou name=71e quartier administratif
ou name=administratif_police_7511871
Franchement... ça ne me dérange pas, ce truc n'a aucune existence de
terrain.
On pourrait aussi faire des articles et des identifiants wikidata
différents pour le "quartier administratif de la Goutte-d'Or" et le
"quartier de la Goutte-d'Or", ce n'est pas la même chose. Vraiment.
Je répète : ce n'est pas la même chose.
Et si quelqu'un veut supprimer le quartier administratif parce que [insérer
ici une raison quelconque]... je dis "pourquoi pas", de toute façon c'est
de la donnée de référence, on la retrouve en open data.

Par contre, si quelqu'un commence à supprimer des quartiers (au sens
commun), des noeuds place=*, ça ne va pas.
On bascule dans la destruction de données de réel contributeur, de terrain,
ou de connaissance locale.
Une donnée qu'il est difficile de trouver (un peu sur wikipedia) mais
surtout présente dans la mémoire collective.

> La page wikipédia
https://fr.wikipedia.org/wiki/Quartier_de_la_Goutte-d%27Or ne m'aide pas
plus.

Même pas cet extrait ?
> Historiquement, et dans le langage courant, « la Goutte d'Or » fait
généralement référence au sud-ouest du quartier administratif, autour de la
rue de la Goutte-d'Or, entre le boulevard Barbès et les voies ferrées.

Et si on reste sur wikipedia, on a beaucoup de choses à lire...

Par exemple le quartier d'à côté :
https://fr.wikipedia.org/wiki/Ch%C3%A2teau_Rouge_(quartier_de_Paris)
> Château Rouge est un quartier de Paris [...]. De nature informelle, il
fait partie des quartiers administratifs de la Goutte d'Or et de
Clignancourt.

Donc dans le quartier administratif de la Goutte-d'Or, on trouve le
quartier (non-administratif) de la Goutte-d'Or et une partie du quartier
(non-administratif) de Château Rouge.

Sur un autre quartier encore, Batignolles, on trouve la distinction
quartier administratif et quartier (non-administratif)
https://fr.wikipedia.org/wiki/Quartier_des_Batignolles
> Le quartier administratif des Batignolles est délimité [... définition de
l'étendue]
> Aujourd'hui les Batignolles apparaissent souvent comme [... étendue
significativement différente]

Un autre quartier, aucun lien direct avec un quartier administratif :
https://fr.wikipedia.org/wiki/Faubourg_Saint-M%C3%A9dard
> Le faubourg Saint-Médard ou "quartier Mouffetard" est un quartier de
Paris dans le 5e à cheval sur les quartiers administratifs Jardin des
Plantes et Val-de-Grâce.
idem pour le Marais
https://fr.wikipedia.org/wiki/Le_Marais_(quartier_parisien) et
https://fr.wikipedia.org/wiki/Quartier_du_Temple
> Le Marais est un quartier parisien historique (et non pas quartier
administratif)
idem pour https://fr.wikipedia.org/wiki/Quartier_latin_(Paris)
idem pour https://fr.wikipedia.org/wiki/Olympiades_(quartier_parisien)

Pour certains arrondissements, le travail de détails des quartiers est
avancé :
https://fr.wikipedia.org/wiki/13e_arrondissement_de_Paris#Quartiers
https://fr.wikipedia.org/wiki/12e_arrondissement_de_Paris#Quartiers

Toujours sur wikipedia, un article plus général
https://fr.wikipedia.org/wiki/Quartier_de_Paris
> la notion de quartier prend plusieurs significations à Paris :
> dans le langage courant, un quartier désigne un espace urbain pourvu
d'une identité commune sur le plan architectural, social, fonctionnel mais
délimité sans précision : le quartier latin, le Marais, le quartier
asiatique [...].
> dans le champ administratif, chacun des vingt arrondissements est découpé
en quatre quartiers.
> enfin, la mise en place des conseils de quartier s'est basée sur un
nouveau découpage de l'espace parisien en 121 quartiers
[carte des conseils de quartier, pour consultation :
https://www.apur.org/sites/default/files/documents/54.pdf si quelqu'un veut
s'amuser à superposer quartier administratif de la Goutte-d'Or et
périmètres des conseils de quartiers sur la zone...]
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-ca] Local groups as part of import plan

[John Whelan]

The problem is defining and contacting a local group.  Once defined then 
they can make the decision.


I've seen as few as two people make a local group decision on an import 
before now although normally it is done over coffee.


Also we get into who is a local mapper.

Many people have an interest in seeing the data imported but I'm under 
the impression only those with a OpenStreetMap userid who have 
contributed count.


Would anyone care to define a local mapper or group?

Thanks John

Jonathan Brown wrote on 2019-03-15 9:46 AM:


Could we get Stats Can to support a few local groups who want to use a 
common framework for a collaborative research project that addresses a 
sustainable development goal outcome (e.g., the OSM fresh security 
challenge https://wiki.openstreetmap.org/wiki/Food_security and 
https://www.usda.gov/topics/food-and-nutrition/food-security) ?


Jonathan



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


--
Sent from Postbox 

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

Re: [OSM-talk-fr] Quartiers à Paris

[Romain MEHUT]

Ok je comprends mieux et je pense que ça vaudrait le coup d'ajouter un tag
note sur les nœuds pour expliquer la distinction avec les polygones.

Romain

Le jeu. 14 mars 2019 à 21:46, Florimond Berthoux <
florimond.berth...@gmail.com> a écrit :

>
> Voici en orange le périmètre du quartier administratif nommé la Goutte
> d'Or,
> en bleu le quartier usuel (limite floue) :
> https://imgur.com/WxrNrtw
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-at] Vienna Geo Meetup

[Manuela Schmidt]

Hallo Friedrich,

die Meetups sind Treffen mit 2-3 Vorträgen und der Möglichkeit zum 
gegenseitigen Austausch. Hinter dem GeoMeetup stehen 4 Leute (inkl. mir) 
mit unterschiedlichem Geo-Background, die Spaß daran haben, die Wiener 
Geo-Community zusammenzubringen und einen Rahmen zu schaffen, Vorträge 
zu verschiedenen Themen anzubieten. OSM & OpenSource ist uns allen ein 
Anliegen, aber nicht der ausschließliche Fokus der Veranstaltung.


Im Gegensatz zum OSM-Stammtisch organisieren wir einen größeren 
abgetrennten (rauchfreien) Raum mit Beamer, in dem Vorträge möglich 
sind. (Nur zur Info: Anfallende Kosten werden derzeit privat getragen.)


LG Manu


Am 15.03.2019 um 14:44 schrieb Friedrich Volkmann:

On 15.03.19 13:29, Stephan Bösch-Plepelits wrote:

Ich glaub es ging hier noch nicht über die Mailingliste: Am 20.3. ist
wieder Vienna Geo Meetup:
https://www.meetup.com/de-DE/ViennaGeo/events/259569831/


Kannst du erklären, was und für wen das ist, bzw. was der Unterschied 
ist zum Wiener OSM-Stammtisch?




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

Re: [Talk-it] name, operator e official_name

[Federico Cortese]

On Fri, Mar 15, 2019 at 2:44 PM demon_box  wrote:
>
> name="Officina Meccanica Fratelli Ronchini"
> operator="Officina Meccanica Fratelli Ronchini Sergio, Roberto e Ezio
> S.n.c."
Secondo me va bene così.

> name="Gelateria Pinguino"
> operator="Rossi Mario S.r.l." oppure anche in questo caso
> operator="Gelateria Pinguino di Rossi Mario S.r.l."?
>

In questo caso direi la seconda.
Se hai la partita IVA puoi anche verificare la denominazione ufficiale su:
https://telematici.agenziaentrate.gov.it/VerificaPIVA/Scegli.do?parameter=verificaPiva

Ciao,
Federico

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

Re: [Talk-ca] Local groups as part of import plan

[Jonathan Brown]

Could we get Stats Can to support a few local groups who want to use a common 
framework for a collaborative research project that addresses a sustainable 
development goal outcome (e.g., the OSM fresh security challenge 
https://wiki.openstreetmap.org/wiki/Food_security and 
https://www.usda.gov/topics/food-and-nutrition/food-security) ? 

Jonathan 

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

Re: [talk-cz] WeeklyOSM CZ 449

[Tom Ka]

Nezkontroloval jsem anglicky original, ktery je take nevhodne
formulovan. Kazdopadne diky za postreh a upraveno.

Bye

čt 14. 3. 2019 v 12:46 odesílatel Mikoláš Štrajt  napsal:
>
> našel jsem tam chybku
>
> > Na mail listu talk-gb se Frederik Ramm ptá, zda někdo nezná nějakou 
> > neziskovou organizaci, která kvůli nejasnostem okolo Brexitu přesunula své 
> > sídlo mimo Velkou Británii. Simon Poole přidává několik dalších možných 
> > důvodů, například i to, že Spojené království nemá vhodnou právní formu pro 
> > organizace typu OpenStreetMap.
>
> až na to, že to nepřidává Simon Poole ale opět Frederik Ramm (na základě 
> otázky z publika)
>
> Ale každopádně je to zajímavé čtení a vůbec by mě nenapadlo, že se může 
> Brexit nějak promítnout do provozu OSM.
>
> --
> Severák
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz

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

Re: [Talk-at] Vienna Geo Meetup

[Friedrich Volkmann]

On 15.03.19 13:29, Stephan Bösch-Plepelits wrote:

Ich glaub es ging hier noch nicht über die Mailingliste: Am 20.3. ist
wieder Vienna Geo Meetup:
https://www.meetup.com/de-DE/ViennaGeo/events/259569831/


Kannst du erklären, was und für wen das ist, bzw. was der Unterschied ist 
zum Wiener OSM-Stammtisch?


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

[Talk-it] name, operator e official_name

[demon_box]

ciao, scusate la ridondanza del mio quesito ma vado ancora in crisi (anche)
su questo punto:

ho il nome di di una ditta:

Officina Meccanica Fratelli Ronchini Sergio, Roberto e Ezio S.n.c.

come me la gioco tra name, operator ed eventualmente official_name?

ipotesi1

name="Officina Meccanica Fratelli Ronchini"
operator="Officina Meccanica Fratelli Ronchini Sergio, Roberto e Ezio
S.n.c."


altro esempio:

Gelateria Pinguino di Rossi Mario S.r.l.

ipotesi1:

name="Gelateria Pinguino"
operator="Rossi Mario S.r.l." oppure anche in questo caso
operator="Gelateria Pinguino di Rossi Mario S.r.l."?

che ne dite?
grazie

--enrico




--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

[OSM-ja] 提案 highway=living_street

[yuu hayashi]

hayashiです

「Living
street」や「生活道路」といった'言語'にとらわれずに「Wikiページ:JA:Tag:highway=living_street」を見てみると、「徐行」区間が一番近いように思えました。

1. Wikipedia「徐行」を見ると各国の'livins street'ぽい「SLOW」標識の写真が掲載されています
2.
徐行の具体的な速度は示されていないですが、FM横浜の2019-03-12放送の「運転クイズ」にて「徐行は10k以下」と紹介されました（過去にTalk-jaで示された7kとか10kに最も近い値です）

「highway=living_street」に割り当てる場合に、「徐行」標識の有無が識別の指標として使えると思います。

ただし、「徐行」に設定される箇所は[wikipedia 徐行]にもあるように「生活道路」以外にも設置されます。
* 工場や企業の敷地内の道路（「構内徐行」の表示あり/１０ｋｍ制限）
* 大規模商業施設内の駐車場通路
* 団地やマンション等の居住者用通路（「団地内徐行」の看板あり）

「企業敷地」や「商業施設」の「徐行」区間を除外するために highway=service と living_street
とを区別する方法を考える必要があると思います。

逆に、なぜか「徐行」標識がないものに
* アーケード商店街の通路
があります。「アーケード通り」は一見、「歩行者専用」に見えるが実は車両の通行が規制されていない場合が意外と多いです。現在はこのようなアーケード通路に
highway=living_street がタグ付けされている箇所が多々あります。

私の意見としては、

「徐行」の表示がなくとも「歩行者専用道路」と認識されるような実質的な「徐行」道路も「徐行に準じる制限が示されている」と解釈して、

* 「徐行」に表示やそれに準じる制限が示された 団地等の居住施設の敷地内通路
* 「徐行」に表示やそれに準じる制限が示された アーケード通りや商店街の通路（例：巣鴨の地蔵通り(176116031)）
などを highway=living_street とする

または、上記のような付帯条件をいろいろとつけなければ highway=living_street を定義することができないのならば、
いっそのこと、現行どおり、日本では highway=living_street は使わない。（将来、日本にもliving
streetの制度ができたときのためにリザーブしておく）

という考えもありだと思っています
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] Quartiers

[Léo El Amri via Talk-fr]

On 15/03/2019 13:58, Rpnpif wrote:
> Le 14 mars 2019, marc marc a écrit :
>> Le 14.03.19 à 09:47, Rpnpif a écrit :
>>> Et quand une commune, assemblage de villages, devient une « place » dans
>>> le sens où son nom est utilisé dans la vie quotidienne des habitants
>>> comme un lieu géographique de vie (par exemple, un livreur veut un
>>> emplacement pour la nouvelle commune sachant que l'admin_center n'a
>>> pas le même nom), que fait-on ?  
>>
>> je comprend pas le problème.
>> si une commune A est un assemblage des villages B (l'admin_center) C D,
>> Rien n’empêche le livreur de chercher A.
>>
>> PS: j'ai la naïve impression que le livreur va plutôt chercher no,rue, 
>> village plut'ot que le nom de la commune :)
> 
> Parce que le niveau commune (nouvelle) est souvent mal géré par les
> applications clientes.
> 
> Le livreur ne cherchera pas le nom du village (ancienne commune) parce
> que de plus en plus il est absent des adresses.
> 
> Alors que l'on devrait avoir sur les adresses :
> N° rue (ou lieu-dit)
> Village (ancienne commune)
> Commune (nouvelle)
> 
> Les adresses comportent plus souvent :
> N° rue (ou lieu-dit)
> Commune (nouvelle)
> 
> De plus, comme il y a encore souvent des lieux-dits homonymes entre les
> anciennes communes d'une même commune nouvelle, bonjour le jeu de piste.

Personnellement je n'ai eu des problème de livraison qu'en ville, et
jamais en rase campagne altiligérienne, alors qu'on a pourtant le même
nom de village (Lieu-dit) dans deux communes qui portent quasiment le
même nom et qui ont le même code postal...

On a une norme pour les addresses assez potable en france. Et le N° rue
(ou lieu-dit) + Commune (nouvelle) est sensé être compatible.

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

Re: [Talk-ca] Building import in BC and Quebec

[John Whelan]

If the local mappers in Alberta or BC feel the data quality is not good 
enough then I think it is up to them to take action but I think it 
really is up to the local mapping community and defining them is 
difficult sometimes.  Also remember agreements within the local 
community are not always electronic in nature.


This is not as simple and clear cut as one might like.

Cheerio John

Jarek Piórkowski wrote on 2019-03-15 8:28 AM:

IMO the huron/hamptonavemapper import is quite clearly in active
disagreement with the import suspension - while I could believe that
one user could overlook clicking on the wiki link in their changeset
messages just once and seeing the bold "on hold", setting up a brand
new similarly named account on February 15, 2019 and immediately
starting to import suggests they know what they're doing. And it's not
like one ultimately _needs_ the tasking manager to insert the data.

The question is what are we going to do about it? Are you going to
speak for Alberta and BC in opposing this import, Nate? That's
defensible but also debatable.

--Jarek

On Thu, 14 Mar 2019 at 21:12, Nate Wessel  wrote:

I would suggest, again, that the tasking manager for this import be locked or 
taken down if that is not possible. One good way to stop people from importing 
when we don't have consensus is to not make it so easy for them. Indeed, I 
would find it plausible if these people said they didn't even know the import 
was paused - their evidence: that the tasking manager is still active!

Best,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com

On 3/14/19 7:42 PM, Jarek Piórkowski wrote:

The changeset comment messages link to the Stats Canada import plan on
the OSM wiki.

I missed it but there were also some edits in Alberta. Quebec edits I
saw were only a couple, outside of Quebec.

http://tasks.osmcanada.ca/project/148 has also been updated, and the
Alberta tasks.

It does raise the point that with a country this large, with editor
community this sparse, there are very few ways to enforce or police a
countrywide consensus, or even arrive at one. Maybe BC mappers like
the import, square angles or no? (Does anyone go to the Metrotown
Meetup?)

--Jarek

On Thu, 14 Mar 2019 at 19:36, john whelan  wrote:

Wicked lad importing without an import plan?

Ask him nicely where the import plan for their imports is.

Looks like a new mapper so may not know the rules.

I think currently there are two sets of data that are licensed for import, the 
Stats Can stuff and the Microsoft stuff.  I haven't seen any import plan for 
the Microsoft stuff but unfortunately it's probably fairly easy to import on 
the Stats Can side my feeling is we need to work out who the locals are to get 
buy in since Canada wide there is no consensus on what is acceptable.  After a 
request from a local group then I think that particular area can proceed.

Quebec I think is being organised by Tim.

Thanks John

On Thu, 14 Mar 2019 at 18:56, Jarek Piórkowski  wrote:

Are people aware that there are buildings being imported by
https://www.openstreetmap.org/user/huronavemapper (most recent 12
hours ago) and https://www.openstreetmap.org/user/hamptonavemapper
(most recent 5 days ago)?

I notice the wiki still says the import is on hold.

Thanks,
--Jarek

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

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

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

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


--
Sent from Postbox 

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

Re: [OSM-talk-fr] adressage dans les zones sans nom de voie - exemple un aérodrome

[Vincent de Château-Thierry]

> De: "Jérôme Seigneuret" 
> 
> PS hors optique Lieudit tu as le même problème sur les gros complexes
> résidentielle avec numéro voir numéro + Lettre, Numéro plus nom de
> batiment et sans pour autant avoir un nm de rue. En région
> parisienne je suis confronté régulièrement à ce problème. Certains
> on patché ça en mettant le nom de la résidence sur la voirie et fait
> de même sur les numéros d'adresse. Ducoup il y a pas mal de nom de
> voie dans BANO avec lotissement * ou résidence * qui n'ont pas de
> réelle existance.
> 
> As tu pris ça en compte dans la V2?

Je n'ai pas touché aux logiques métier dans la v2, c'est surtout une version 
qui permet de mieux coller aux versions courantes de Fantoir et Cadastre 
durablement, en profitant des publications sur data.gouv.fr. Donc je ne pense 
pas que ça soit plus géré qu'avant, mais je veux bien les exemples dont tu 
parles histoire d'appréhender le sujet concrètement. Tu peux en indiquer ici, 
ou directement créer un ticket => https://github.com/osm-fr/bano/issues/new

merci
vincent

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

Re: [OSM-talk-fr] Quartiers

[Rpnpif]

Le 14 mars 2019, marc marc a écrit :

> Le 14.03.19 à 09:47, Rpnpif a écrit :
> > Et quand une commune, assemblage de villages, devient une « place » dans
> > le sens où son nom est utilisé dans la vie quotidienne des habitants
> > comme un lieu géographique de vie (par exemple, un livreur veut un
> > emplacement pour la nouvelle commune sachant que l'admin_center n'a
> > pas le même nom), que fait-on ?  
> 
> je comprend pas le problème.
> si une commune A est un assemblage des villages B (l'admin_center) C D,
> Rien n’empêche le livreur de chercher A.
> 
> PS: j'ai la naïve impression que le livreur va plutôt chercher no,rue, 
> village plut'ot que le nom de la commune :)

Parce que le niveau commune (nouvelle) est souvent mal géré par les
applications clientes.

Le livreur ne cherchera pas le nom du village (ancienne commune) parce
que de plus en plus il est absent des adresses.

Alors que l'on devrait avoir sur les adresses :
N° rue (ou lieu-dit)
Village (ancienne commune)
Commune (nouvelle)

Les adresses comportent plus souvent :
N° rue (ou lieu-dit)
Commune (nouvelle)

De plus, comme il y a encore souvent des lieux-dits homonymes entre les
anciennes communes d'une même commune nouvelle, bonjour le jeu de piste.

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] Calcul d'itinéraire avec OSRM - questionnement calcul

[Frédéric Rodrigo]

Le 15/03/2019 à 00:53, Violaine_Do a écrit :

Bonjour tout le monde,

Je me demandais comment améliorer le calcul d'itinéraire, avec OSRM 
(sur osm.org) en fonction de conditions locales (cf profil voiture 
utilisé sur OSM.org 1)


Pour le moment primary, secondary et tertiary ne montent par défaut 
pas a plus de 65km/h, les exceptions rurales sont souvent au dessus.. 
(cf wiki speed limits : 2, par exemple pour les routes rurales en 
france on a comme tag maxspeed=80 + source:maxspeed=FR:rural) Donc 
avec maxspeed on dépasse la vitesse par défaut du type de route 
tertiary, secondary, primary. Mais pour avoir fait un petit test, je 
comprends pas le calcul, par exemple avec un tronçon en particulier 
(3) : je ne trouve pas la vitesse attendue (j'aimerais que le calcul 
prenne en compte la vitesse rurale c'est à dire 80km/h plutôt que la 
vitesse du type de route secondary qui est à 55km/h, information qui 
est présente sur ce tronçon). Est-ce que c'est parce que 
primary/secondary/tertiary sont prioritaires/contraignent le reste? 
(en gros faudrait il changer les vitesses par defaut 
primary/secondary/tertiary pour permettre l'utilisation des 
maxspeed?). J'espère que je suis assez compréhensible...


Bonne soirée/journée,

Violaine

1: 
https://github.com/fossgis-routing-server/cbf-routing-profiles/blob/master/car.lua 



2:https://wiki.openstreetmap.org/wiki/Speed_limits

3: 
https://www.openstreetmap.org/directions?engine=fossgis_osrm_car=49.6435%2C3.3967%3B49.6206%2C3.4528#map=14/49.6343/3.4309 





OSRM ne va jamais te proposer de rouler à maxpseed. La vitesse retourné 
par OSRM est une vitesse moyenne de parcours. Sur un tronçon en ligne 
droite de nationale, tu va rouler à maxspeed, mais ça ne va pas être le 
cas pour un vrais trajet en prenant en compte un vitesse plus moyenne.


Ensuite OSRM n'est pas pas capable tout seule de faire la distinction 
entre zone urbaine et rurale. Même en utilisant les bons types de voies 
et bon maxspeed. On ne va pas rouler à la même vitesse moyenne en ville 
ou à la campagne pour une même limitation à 50km/h par ex.


Pour répondre à ce problème j'avais fait une modif du profil d'OSMR, 
mais en utilisant des données externes pour avoir un contexte urbain / 
non urbain :


https://github.com/Project-OSRM/osrm-profiles-contrib/tree/master/5/18/urban-density

https://www.mapotempo.com/calcul-itineraire-densite-urbaine-mapotempo-web/


Frédéric.



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

Re: [Talk-ca] Building import in BC and Quebec

[Jarek Piórkowski]

IMO the huron/hamptonavemapper import is quite clearly in active
disagreement with the import suspension - while I could believe that
one user could overlook clicking on the wiki link in their changeset
messages just once and seeing the bold "on hold", setting up a brand
new similarly named account on February 15, 2019 and immediately
starting to import suggests they know what they're doing. And it's not
like one ultimately _needs_ the tasking manager to insert the data.

The question is what are we going to do about it? Are you going to
speak for Alberta and BC in opposing this import, Nate? That's
defensible but also debatable.

--Jarek

On Thu, 14 Mar 2019 at 21:12, Nate Wessel  wrote:
>
> I would suggest, again, that the tasking manager for this import be locked or 
> taken down if that is not possible. One good way to stop people from 
> importing when we don't have consensus is to not make it so easy for them. 
> Indeed, I would find it plausible if these people said they didn't even know 
> the import was paused - their evidence: that the tasking manager is still 
> active!
>
> Best,
>
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com
>
> On 3/14/19 7:42 PM, Jarek Piórkowski wrote:
>
> The changeset comment messages link to the Stats Canada import plan on
> the OSM wiki.
>
> I missed it but there were also some edits in Alberta. Quebec edits I
> saw were only a couple, outside of Quebec.
>
> http://tasks.osmcanada.ca/project/148 has also been updated, and the
> Alberta tasks.
>
> It does raise the point that with a country this large, with editor
> community this sparse, there are very few ways to enforce or police a
> countrywide consensus, or even arrive at one. Maybe BC mappers like
> the import, square angles or no? (Does anyone go to the Metrotown
> Meetup?)
>
> --Jarek
>
> On Thu, 14 Mar 2019 at 19:36, john whelan  wrote:
>
> Wicked lad importing without an import plan?
>
> Ask him nicely where the import plan for their imports is.
>
> Looks like a new mapper so may not know the rules.
>
> I think currently there are two sets of data that are licensed for import, 
> the Stats Can stuff and the Microsoft stuff.  I haven't seen any import plan 
> for the Microsoft stuff but unfortunately it's probably fairly easy to import 
> on the Stats Can side my feeling is we need to work out who the locals are to 
> get buy in since Canada wide there is no consensus on what is acceptable.  
> After a request from a local group then I think that particular area can 
> proceed.
>
> Quebec I think is being organised by Tim.
>
> Thanks John
>
> On Thu, 14 Mar 2019 at 18:56, Jarek Piórkowski  wrote:
>
> Are people aware that there are buildings being imported by
> https://www.openstreetmap.org/user/huronavemapper (most recent 12
> hours ago) and https://www.openstreetmap.org/user/hamptonavemapper
> (most recent 5 days ago)?
>
> I notice the wiki still says the import is on hold.
>
> Thanks,
> --Jarek
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca

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

[Talk-at] Vienna Geo Meetup

[Stephan Bösch-Plepelits]

Hi!

Ich glaub es ging hier noch nicht über die Mailingliste: Am 20.3. ist
wieder Vienna Geo Meetup:
https://www.meetup.com/de-DE/ViennaGeo/events/259569831/

Ich werd was über Overpass API erzählen.

Kommt zuhauf!

gruesse,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,--.
| Stephan Bösch-Plepelits  ❤ code ❤ urbanism ❤ free software ❤ cycling |
| Projects:|
| > OpenStreetMap: openstreetbrowser.org > openstreetmap.at|
| > Urbanism: Radlobby Wien|
| Contact: |
| > Mail: sk...@xover.mud.at > Blog: plepe.at > Code: github.com/plepe |
| > Twitter: twitter.com/plepe > Jabber: sk...@jabber.at   |
| > Mastodon: @pl...@en.osm.town   |
`--'


signature.asc
Description: Digital signature
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [OSM-talk-fr] adressage dans les zones sans nom de voie - exemple un aérodrome

[Jérôme Seigneuret]

OK,

Bon dans tous les cas c'est fait pour les adresses de l'aérodrome il me
manque en effet l'ajout du fantoir car c'est aussi connu sous le nom
d'aéroport ( les panneaux affiche ça...)

Dans tous les cas Merci

PS hors optique Lieudit tu as le même problème sur les gros complexes
résidentielle avec numéro voir numéro + Lettre, Numéro plus nom de batiment
et sans pour autant avoir un nm de rue. En région parisienne je suis
confronté régulièrement à ce problème. Certains on patché ça en mettant le
nom de la résidence sur la voirie et fait de même sur les numéros
d'adresse. Ducoup il y a pas mal de nom de voie dans BANO avec lotissement
* ou résidence * qui n'ont pas de réelle existance.

As tu pris ça en compte dans la V2?

Merci

Le ven. 15 mars 2019 à 11:17, Vincent de Château-Thierry 
a écrit :

> Bonjour,
>
> > De: "Jérôme Seigneuret" 
> > Le jeu. 14 mars 2019 à 23:21, marc marc < marc_marc_...@hotmail.com >
> > a écrit :
> >
> >
> > Le 14.03.19 à 23:13, Jérôme Seigneuret a écrit :
> >
> > > définir des adresses dans un aéroport ou un aérodrome?
> >
> > si l'adresse n'as pas de nom de rue,
> > c'est addr:place qu'il convient d'utiliser
> > https://wiki.openstreetmap.org/wiki/Key:addr
> >
> > > J'ai des adresses mais ça match pas avec nomminatim et ça remonte
> > > pas
> > > correctement dans BANO.
> > >
> https://www.openstreetmap.org/#map=20/48.74816937651511/2.117237893582972
> >
> > un no sans rue/lieu ne peux à mon avis pas matcher.
> > nominatime gère addr:palce
> > aucune idée pour bano
>
> Pour BANO si le but est de dégommer le nom en rouge "Aerodrome Toussus le
> Noble" alors il suffit d'ajouter son code Fantoir sur l'aerodrome lui-même
> : https://www.openstreetmap.org/way/236395648
> Dans le cadastre je vois 42 adresses dont le nom de voie est "Aerodrome
> Toussus le Noble". Pour celles-ci en effet ça aurait du sens de modéliser
> avec addr:place="Aerodrome Toussus le Noble", mais indépendamment de BANO
> qui pour l'instant ne tient pas compte de ce tag. Ca a été évoqué ici :
> https://github.com/osm-fr/bano/issues/50 mais dans une optique lieu-dit,
> alors qu'on parle d'adresse numérotée pour l'aérodrome. Ca devrait faire
> l'objet d'un autre ticket, dont acte :
> https://github.com/osm-fr/bano/issues/149. Pas sûr que ça sorte avec la
> v2 de BANO qui apparaîtra dans quelques semaines mais au moins c'est tracé.
>
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr