date:20190704

いいださん：
助言ありがとうございます。

入れ違いで、クロスポストでの投稿をしてきてしまいました。(legal-talkは過疎っていると思ったので…)
そこで、talkへは議論をlegal-talkに集約することの案内、legal-talkへは返信のメールアドレスからtalkとtalk-jaを取り除くことのお願いをしてきました。
talk-jaの皆様におかれましても、先の英語メールに対してのご意見・ご感想がございましたらlegal-talkを購読の上返信していただきますようお願いいたします。
ご不便をおかけして申し訳ございません。

石野 貴之
yumean1...@gmail.com
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-it] Mapping campi rom

2019-07-04 Per discussione canfe

'residential=halting_site' direi di no dato che non son mai 'temporanei'
bensì stabili.
Più realisticamente (si mappa quel che c'è non quel che si vorrebbe):
building=static_caravan



--
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-legal-talk] Proposal for a revision of JA:Available Data

The previous mail was cross-posted on talk, talk-ja and legal-talk.
However, I was given an  advice to avoid cross-posting and aggregate the
discussion on legal-talk.

Please remove talk and talk-ja from the mail adress when you post your
opinion. I'm really sorry for the inconvenience.
Thank you!

Takayuki Ishino (User: yumean1119)
yumean1...@gmail.com
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

[OSM-talk] Discussion stopped here (Re: Proposal for a revision of JA:Available Data)

Sorry for the readers of talk-ml:

The previous mail was cross-posted on talk, talk-ja and legal-talk.
However, I was given an  advice to avoid cross-posting and aggregate the
discussion on legal-talk.

So, if you are interested in this topic, please subscribe legal-talk and
continue conversation there.
Thank you!

Takayuki Ishino (User: yumean1119)
yumean1...@gmail.com
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Proposal for a revision of JA:Available Data

Hello, everyone. I'm from Okayama, Japan.

"What kind of data can be used in OpenStreetMap?"
Our community has put together common understandings about the issue on the
following page. (written in Japanese)
https://wiki.openstreetmap.org/wiki/JA:Available_Data

Recently, Tomoya Muramoto (user:muramototomoya) proposed for a revision of
this guidline.
https://lists.openstreetmap.org/pipermail/talk-ja/2019-June/010597.html

The table on JA:Available_Data says that we can use data on websites, such
as names, addresses and phone numbers
because they are not copyrighted works but facts. However, Tomoya is
against such a point of view.
He thinks that licences for these data are not ODbL-compatible and that we
should refrain from using them.

We have unanimously agreed that websites which provide secondary
information, including Wikipedia, Wikidata
and curation sites must not be used for sources.

The main point at issue is whether we are allowed to use official websites
that provide primary information or not.
Some of us think that we can use data from official websites unless it is
prohibited by their term of service.
Tomoya is also against using official websites. His opinion is that we
would able to map POIs without surveying on the ground at all
if it was OK to use data from websites.
(example:
https://lists.openstreetmap.org/pipermail/talk-ja/2019-June/010604.html )

We agreed that this is about on the basis of OSM and the discussion should
not be brought to an end in the Japanese community.

What do you think about the issue? We would like to hear your honest
opinion.

Thank you.

Takayuki Ishino (User: yumean1119)
yumean1...@gmail.com
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-ja] Proposal for a revision of JA:Available Data

2019-07-04 Per discussione Satoshi IIDA

いいだです。

投稿ありがとうございます。
クロスポストは嫌がられますし、Legal-talkだけで良いと思いますよ。
（こっち方面でつよいひとは、みんなLegal-talkみてるし反応するので）




2019年7月5日(金) 12:20 石野貴之 :

> legal-talk, talkは購読中でないと投稿を受け付けないようなので、購読手続きをしてから再送します。
>
> 石野 貴之
> yumean1...@gmail.com
>
>> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>


-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

[OSM-legal-talk] Proposal for a revision of JA:Available Data

Hello, everyone. I'm from Okayama, Japan.

"What kind of data can be used in OpenStreetMap?"
Our community has put together common understandings about the issue on the
following page. (written in Japanese)
https://wiki.openstreetmap.org/wiki/JA:Available_Data

Recently, Tomoya Muramoto (user:muramototomoya) proposed for a revision of
this guidline.
https://lists.openstreetmap.org/pipermail/talk-ja/2019-June/010597.html

The table on JA:Available_Data says that we can use data on websites, such
as names, addresses and phone numbers
because they are not copyrighted works but facts. However, Tomoya is
against such a point of view.
He thinks that licences for these data are not ODbL-compatible and that we
should refrain from using them.

We have unanimously agreed that websites which provide secondary
information, including Wikipedia, Wikidata
and curation sites must not be used for sources.

The main point at issue is whether we are allowed to use official websites
that provide primary information or not.
Some of us think that we can use data from official websites unless it is
prohibited by their term of service.
Tomoya is also against using official websites. His opinion is that we
would able to map POIs without surveying on the ground at all
if it was OK to use data from websites.
(example:
https://lists.openstreetmap.org/pipermail/talk-ja/2019-June/010604.html )

We agreed that this is about on the basis of OSM and the discussion should
not be brought to an end in the Japanese community.

What do you think about the issue? We would like to hear your honest
opinion.

Thank you.

Takayuki Ishino (User: yumean1119)
yumean1...@gmail.com
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

[OSM-ja] Proposal for a revision of JA:Available Data

Hello, everyone. I'm from Okayama, Japan.

"What kind of data can be used in OpenStreetMap?"
Our community has put together common understandings about the issue on the
following page. (written in Japanese)
https://wiki.openstreetmap.org/wiki/JA:Available_Data

Recently, Tomoya Muramoto (user:muramototomoya) proposed for a revision of
this guidline.
https://lists.openstreetmap.org/pipermail/talk-ja/2019-June/010597.html

The table on JA:Available_Data says that we can use data on websites, such
as names, addresses and phone numbers
because they are not copyrighted works but facts. However, Tomoya is
against such a point of view.
He thinks that licences for these data are not ODbL-compatible and that we
should refrain from using them.

We have unanimously agreed that websites which provide secondary
information, including Wikipedia, Wikidata
and curation sites must not be used for sources.

The main point at issue is whether we are allowed to use official websites
that provide primary information or not.
Some of us think that we can use data from official websites unless it is
prohibited by their term of service.
Tomoya is also against using official websites. His opinion is that we
would able to map POIs without surveying on the ground at all
if it was OK to use data from websites.
(example:
https://lists.openstreetmap.org/pipermail/talk-ja/2019-June/010604.html )

We agreed that this is about on the basis of OSM and the discussion should
not be brought to an end in the Japanese community.

What do you think about the issue? We would like to hear your honest
opinion.

Thank you.

Takayuki Ishino (User: yumean1119)
yumean1...@gmail.com
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-ja] Proposal for a revision of JA:Available Data

legal-talk, talkは購読中でないと投稿を受け付けないようなので、購読手続きをしてから再送します。

石野 貴之
yumean1...@gmail.com

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

Re: [OSM-talk] Reordering and rewriting Good Practice wiki page

2019-07-04 Per discussione 80hnhtv4agou--- via talk


the bing imagery is from 2016, but i live where i map.
 
From: Joseph Eisenberg
Sent: Thursday, July 4, 2019 10:08 PM
To: Yves
Cc: osm
Subject: Re: [OSM-talk] Reordering and rewriting Good Practice wiki 
page
 
I've 
finished the new detailed page "Keep the History"

And so I've removed the 
two paragraphs about specific JOSM plugins and
a way to move a node to a new 
area from the Good_practice page - they
are on the new page which is 
linked

https://wiki.openstreetmap.org/wiki/Keep_the_history

I 
would also like to move "Check the history of important objects" to
the new 
page, since I think it is redundant on Good practice where
it's mentioned in 
"Do not trace from outdated imagery"

But I'm still waiting to hear back 
from the original author who added
this section 
at
https://wiki.openstreetmap.org/wiki/Talk:Good_practice#Section:_.22Check_the_history_of_important_objects.22
 :

Joseph

On 
7/4/19, Joseph Eisenberg < joseph.eisenb...@gmail.com > wrote:
> As 
mentioned, I plan to significantly shorten the "Keep the history"
> 
section, with a link to the longer version at
>  https://wiki.openstreetmap.org/wiki/Keep_the_history instead.
>
> I 
would probably support shortening the page even further, but I've
> 
already had several edits reverted by other users who are in favor of
> 
including various sections.
>
> On 7/4/19, Yves 
< yve...@mailbox.org > wrote:
>> Hmm... I would be all in favor of 
extending the See also... section and
>> shorten drastically the page 
to keep it simple.
>> Some of the good practices there are second 
order, don't you think?
>> Keeping history compared to Tag for the 
renderer, for example.
>> Yves
>>
>> Le 4 juillet 
2019 05:53:23 GMT+02:00, Joseph Eisenberg
>> 
< joseph.eisenb...@gmail.com > a écrit :
>>>I've reordered and 
reworded several sections of the Good practice
>>>page:  https://wiki.openstreetmap.org/wiki/Good_practice
>>>
>>>The 
page had grown over the years from 6 or 7 initial 
sections:
>>>(First verion of page in 
2008
>>> https://wiki.openstreetmap.org/w/index.php?title=Good_practice=86242 )
>>>
>>>1) 
Don't map for the renderer
>>>2) One feature, one 
OSM-object
>>>3) Keep straight ways straight
>>>4) Map 
what's on the ground
>>>5)a) Don't remove tags you don't 
understand
>>>   b) Document your 
custom-tags
>>>6) Do correct 
errors
>>>
>>>Now there were 22 different sections, 
several added this past year
>>>without discussion, and they were 
not 
organized:
>>> https://wiki.openstreetmap.org/w/index.php?title=Good_practice=1861565
>>>
>>>I've 
reordered and categorized these sections under 7 main 
headings:
>>>
>>>1 Do correct errors
>>>2 
Verifiability (+Map what's on the ground, Don't map: 
historic
>>>events, temporary features, local legislation 
etc)
>>>3 Don't map for the renderer (+ Don't misuse name 
tag)
>>>4 Good changeset comments (+Keep the 
history)
>>>5 One feature, one OSM element
>>>6 Editing 
Standards: (Align aerial imagery before tracing, Do not
>>>trace 
from outdated imagery... Keep straight ways straight ... 
Mark
>>>estimations with FIXME ... etc.)
>>>7 Document 
your custom-tags (Don't remove tags that you 
don't
>>>understand...
>>>
>>>I've made some 
wording changes for more consistent and concise style,
>>>and 
removed some examples (eg abandoned 
railways)
>>>
>>>I've removed 2 sections added in the 
past year:
>>>
>>>"Don't map insignificant, perishable 
and mobile objects"
>>>- this section duplicated information in the 
exiting heading about
>>>temporary 
features
>>>
>>>"Don't censor anything existing in 
reality for any reason. Avoid
>>>interpolations if there is 
sufficient imagery."
>>>- This seems redundant and the part about 
censoring data isn't
>>>completely correct. We don't add personal 
info about who lives in a
>>>private house, for 
example.
>>>
>>>While I haven't done this yet, I would 
also recommend moving the long
>>>details about "Keep the history", 
involving how to use specific
>>>editors and checking history in 
certain editors, along with the
>>>section "Check the history of 
important objects" which duplicates
>>>advice in the Aerial Imagery 
section, to a new page, with a 
link:
>>> https://wiki.openstreetmap.org/wiki/Keep_the_history
>>>
>>>Joseph 
Eisenberg, 
User:Jeisenbe
>>>
>>>___
>>>talk 
mailing 
list
>>>talk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk
>>
>

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

Re: [talk-cz] Rozcestník a bod záchrany, jako jeden nebo dva body?

2019-07-04 Per discussione Tom Ka

Ahoj,

ciste podle pravidel by to mel byt asi jeden bod, ale ja v tomhle spise
zastavam nazor, ze mapuju logicke objekty, takze rozcestnik jeden bod (i
kdyz jsou hned vedle sebe sloupky dva) a hned vedle druhy s emergency. Ono
je pekne nemapovat pro renderer ale nektere veci se v nem resi dost spatne
a obtizne (i kdyz tohle neni takova hruza) a tak povazuju za dobre pouzivat
hlavne selsky rozum. U fotek Fody je to neco jineho, tam taguji co je na
fotce a snazim se resit tim, ze fotim kazdy objekt zvlast (treba mapu vedle
rozcestniku). Zde je ale asi jediny realny problem s nemoznosti mit ikony
pro uplne vsechny kombinace tagu jedne fotky pro vrstvu na osmap.cz.

Bye

On Thu, Jul 4, 2019, 23:43 majka  wrote:

> Jak značit bod záchrany, který je umístěný přímo na rozcestníku? Například
> tady 
> Dát jako samostatný bod, nebo připojit k bodu rozcestníku?
> ___
> 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: [OSM-talk] Reordering and rewriting Good Practice wiki page

2019-07-04 Per discussione Joseph Eisenberg

I've finished the new detailed page "Keep the History"

And so I've removed the two paragraphs about specific JOSM plugins and
a way to move a node to a new area from the Good_practice page - they
are on the new page which is linked

https://wiki.openstreetmap.org/wiki/Keep_the_history

I would also like to move "Check the history of important objects" to
the new page, since I think it is redundant on Good practice where
it's mentioned in "Do not trace from outdated imagery"

But I'm still waiting to hear back from the original author who added
this section at
https://wiki.openstreetmap.org/wiki/Talk:Good_practice#Section:_.22Check_the_history_of_important_objects.22:

Joseph

On 7/4/19, Joseph Eisenberg  wrote:
> As mentioned, I plan to significantly shorten the "Keep the history"
> section, with a link to the longer version at
> https://wiki.openstreetmap.org/wiki/Keep_the_history instead.
>
> I would probably support shortening the page even further, but I've
> already had several edits reverted by other users who are in favor of
> including various sections.
>
> On 7/4/19, Yves  wrote:
>> Hmm... I would be all in favor of extending the See also... section and
>> shorten drastically the page to keep it simple.
>> Some of the good practices there are second order, don't you think?
>> Keeping history compared to Tag for the renderer, for example.
>> Yves
>>
>> Le 4 juillet 2019 05:53:23 GMT+02:00, Joseph Eisenberg
>>  a écrit :
>>>I've reordered and reworded several sections of the Good practice
>>>page: https://wiki.openstreetmap.org/wiki/Good_practice
>>>
>>>The page had grown over the years from 6 or 7 initial sections:
>>>(First verion of page in 2008
>>>https://wiki.openstreetmap.org/w/index.php?title=Good_practice=86242)
>>>
>>>1) Don't map for the renderer
>>>2) One feature, one OSM-object
>>>3) Keep straight ways straight
>>>4) Map what's on the ground
>>>5)a) Don't remove tags you don't understand
>>>   b) Document your custom-tags
>>>6) Do correct errors
>>>
>>>Now there were 22 different sections, several added this past year
>>>without discussion, and they were not organized:
>>>https://wiki.openstreetmap.org/w/index.php?title=Good_practice=1861565
>>>
>>>I've reordered and categorized these sections under 7 main headings:
>>>
>>>1Do correct errors
>>>2Verifiability (+Map what's on the ground, Don't map: historic
>>>events, temporary features, local legislation etc)
>>>3Don't map for the renderer (+ Don't misuse name tag)
>>>4Good changeset comments (+Keep the history)
>>>5One feature, one OSM element
>>>6Editing Standards: (Align aerial imagery before tracing, Do not
>>>trace from outdated imagery... Keep straight ways straight ... Mark
>>>estimations with FIXME ... etc.)
>>>7Document your custom-tags (Don't remove tags that you don't
>>>understand...
>>>
>>>I've made some wording changes for more consistent and concise style,
>>>and removed some examples (eg abandoned railways)
>>>
>>>I've removed 2 sections added in the past year:
>>>
>>>"Don't map insignificant, perishable and mobile objects"
>>>- this section duplicated information in the exiting heading about
>>>temporary features
>>>
>>>"Don't censor anything existing in reality for any reason. Avoid
>>>interpolations if there is sufficient imagery."
>>>- This seems redundant and the part about censoring data isn't
>>>completely correct. We don't add personal info about who lives in a
>>>private house, for example.
>>>
>>>While I haven't done this yet, I would also recommend moving the long
>>>details about "Keep the history", involving how to use specific
>>>editors and checking history in certain editors, along with the
>>>section "Check the history of important objects" which duplicates
>>>advice in the Aerial Imagery section, to a new page, with a link:
>>>https://wiki.openstreetmap.org/wiki/Keep_the_history
>>>
>>>Joseph Eisenberg, User:Jeisenbe
>>>
>>>___
>>>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-ja] Proposal for a revision of JA:Available Data

Sorry, I posted the mail without starting new lines. Please reply to this
mail, not to the original one, if you have any opinions.

--Posting Again--
Hello, everyone. I'm from Okayama, Japan.

"What kind of data can be used in OpenStreetMap?"
Our community has put together common understandings about the issue on the
following page. (written in Japanese)
https://wiki.openstreetmap.org/wiki/JA:Available_Data

Recently, Tomoya Muramoto (user:muramototomoya) proposed for a revision of
this guidline.
https://lists.openstreetmap.org/pipermail/talk-ja/2019-June/010597.html

The table on JA:Available_Data says that we can use data on websites, such
as names, addresses and phone numbers
because they are not copyrighted works but facts. However, Tomoya is
against such a point of view.
He thinks that licences for these data are not ODbL-compatible and that we
should refrain from using them.

We have unanimously agreed that websites which provide secondary
information, including Wikipedia, Wikidata
and curation sites must not be used for sources.

The main point at issue is whether we are allowed to use official websites
that provide primary information or not.
Some of us think that we can use data from official websites unless it is
prohibited by their term of service.
Tomoya is also against using official websites. His opinion is that we
would able to map POIs without surveying on the ground at all
if it was OK to use data from websites.
(example:
https://lists.openstreetmap.org/pipermail/talk-ja/2019-June/010604.html )

We agreed that this is about on the basis of OSM and the discussion should
not be brought to an end in the Japanese community.
What do you think about the issue? We would like to hear your honest
opinion.
Thank you.

Takayuki Ishino (User: yumean1119)
yumean1...@gmail.com

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

[OSM-ja] Proposal for a revision of JA:Available Data

Hello, everyone. I'm from Okayama, Japan.
"What kind of data can be used in OpenStreetMap?"
Our community has put together common understandings about the issue on the
following page. (written in Japanese)
https://wiki.openstreetmap.org/wiki/JA:Available_Data
Recently, Tomoya Muramoto (user:muramototomoya) proposed for a revision of
this guidline.
https://lists.openstreetmap.org/pipermail/talk-ja/2019-June/010597.html
The table on JA:Available_Data says that we can use data on websites, such
as names, addresses and phone numbers
because they are not copyrighted works but facts. However, Tomoya is
against such a point of view.
He thinks that licences for these data are not ODbL-compatible and that we
should refrain from using them.
We have unanimously agreed that websites which provide secondary
information, including Wikipedia, Wikidata
and curation sites must not be used for sources.
The main point at issue is whether we are allowed to use official websites
that provide primary information or not.
Some of us think that we can use data from official websites unless it is
prohibited by their term of service.
Tomoya is also against using official websites. His opinion is that we
would able to map POIs without surveying on the ground at all
if it was OK to use data from websites.
(example:
https://lists.openstreetmap.org/pipermail/talk-ja/2019-June/010604.html )
We agreed that this is about on the basis of OSM and the discussion should
not be brought to an end in the Japanese community.
What do you think about the issue? We would like to hear your honest
opinion.
Thank you.
Takayuki Ishino (User: yumean1119)
yumean1...@gmail.com
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk] Reordering and rewriting Good Practice wiki page

2019-07-04 Per discussione Joseph Eisenberg

Re: "Try to keep changesets to a manageable size, both in number of
changes and geographical scope."

This would be good to add to "Good changeset comments"
https://wiki.openstreetmap.org/wiki/Good_changeset_comments

If a changeset covers a huge are or too many changes, it won't be easy
to understand the comments in the future.

It's not usually a problem for iD users, since you get a warning when
over 100 objects have been edited and it's hard to scroll around too
far, but it happens with JOSM and imports.

Many of the issues with too large changesets are related to imports
and mechanical edits, which are not currently discussed on this
Good_practice page but have separate pages:

https://wiki.openstreetmap.org/wiki/Automated_edits
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct

https://wiki.openstreetmap.org/wiki/Import
https://wiki.openstreetmap.org/wiki/Import/Guidelines

On 7/5/19, Warin <61sundow...@gmail.com> wrote:
> On 05/07/19 05:54, Jmapb wrote:
>> On 7/4/2019 12:40 AM, Warin wrote:
>>> On the order of things.
>>>
>>> Best to tell them what to do first. This provides some motivation.
>>>
>>> Leave 'what not to do' for last, these tend to turn people away.
>>>
>>> So I would do:
>>>
>>> 1One feature, one OSM element
>>>
>>> 2Good changeset comments (+Keep the history)
>>>
>>> 3Editing Standards: (Align aerial imagery before tracing, Do not
>>> trace from outdated imagery... Keep straight ways straight ... Mark
>>> estimations with FIXME ... etc.)
>>>
>>> 4Do correct errors
>>>
>>> 5Verifiability (+Map what's on the ground, Don't map: historic
>>> events, temporary features, local legislation etc)
>>>
>>> 6Document your custom-tags (Don't remove tags that you don't
>>> understand...
>>>
>>> 7Don't map for the renderer (+ Don't misuse name tag)
>>
>> I'd personally advocate for one more "don't" -- But it can be phrased as
>> a "do" if that helps the psychology:
>>
>> "Try to keep changesets to a manageable size, both in number of changes
>> and geographical scope."
>>
>> I believe this is commonly understood best practice, but it's only
>> vaguely documented.
>
> +1 .. and guilty of it too (in my early days).
>
>
>
> ___
> 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] Reordering and rewriting Good Practice wiki page

2019-07-04 Per discussione Joseph Eisenberg

You are right. I've moved "Don't map temporary events and temporary
features" to it's own main heading after Verifiability.

I believe "Map what's on the ground", "Don't map historic events" and
"Don't map your local legislation..." are clearly related to
verifiability.

The later two reference "verifiability" in the text, and "Map what's
on the ground" is related, because the text of a sign or other
real-world object is easier to verify than the accuracy of old maps.

On 7/5/19, Tobias Knerr  wrote:
> On 04.07.19 05:53, Joseph Eisenberg wrote:
>> 2Verifiability (+Map what's on the ground, Don't map: historic
>> events, temporary features, local legislation etc)
>
> In my opinion, the practices that you've turned into subheadings of the
> verifiability section are not merely special cases of verifiability.
>
> For example, temporary features are perfectly verifiable (until they
> cease to exist, of course). The reasons why it's not usually considered
> good practice to map them include the unsustainable maintenance effort
> and the impact on offline use of our data.
>
> So I feel these items are really their own separate practices, not part
> of verifiability. If you want to avoid having too many top-level
> headings, you might still be able to group the three "Don't map..."
> rules into a common section.
>
> ___
> 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-ja] 出典明記のwikiページ

2019-07-04 Per discussione Satoshi IIDA

いいだです。
昨晩、ふと過去のメールを見返していて、
新潟県長岡市から、航空写真を公開した旨の連絡をうけていたことを見つけました。
（完全に見逃していた。。。）
OSM wikiにも追記しました。

https://www.city.nagaoka.niigata.jp/shisei/cate10/gis/27.html

OSMでの追加利用許諾はまだもらっていませんが、これから問い合わせをしようと思います。
他の市町村に比べて画質はいささか落ちるようですが、
Bing等の衛星写真画像と比べるとかなりはっきり地物が写り込んでいることがわかります。
全部で400mbくらい、なおかつ飛び地も存在する、ということもあり、
foss4gツールのテスト用ファイルとしてもちょうどよいのではないでしょうか。






2019年7月3日(水) 12:38 Satoshi IIDA :

>
> いいだです。
> ありがとうございます、たいへん便利です！
>
> 鹿児島市が抜けていたので、追記しました。
> matokenさんがタイルを公開されていたような？と思ったのですが、ぱっと出てこなかったので、また後で探します。
>
>
>
>
> 2019年6月29日(土) 10:09 Tomomichi Hayakawa :
>
>> Tomです。
>>
>> 日本の自治体のオープンデータについて調べていまして、
>> 航空写真やオープンデータをOSMで活用する際の出典明記のwikiページを
>> 見つけた分だけリストにしてみました。
>> https://wiki.openstreetmap.org/wiki/User:Tom_G3X/OpenData
>>
>> もし、抜け等がありましたら、教えていただけると嬉しいです。
>> 追記等も大歓迎です。
>>
>> --
>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> はやかわ ともみち (Tomomichi Hayakawa)
>> tom.hayak...@gmail.com
>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> ___
>> Talk-ja mailing list
>> Talk-ja@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ja
>>
>
>
> --
> Satoshi IIDA
> mail: nyamp...@gmail.com
> twitter: @nyampire
>


-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-ja] 名称の次数と住所の次数

石野です。

＞ 石川さん
新たな視点からの投稿ありがとうございます。

2019年7月5日(金) 1:08 ISHIKAWA Takayuki (Talk-ja 経由) :

> こんにちは、奈良の石川です。
>
> すでに talk-ja でなく talk に場を移してしまったかも知れませんが、私が talk-ja
> しか購読していないので、ここに書かせて下さい。(反応が遅くてすみません。)
>

実のところ、まだ始まってすらいません。下手な英語でよければ、私がtalk-jaで出た意見をとりまとめてtalkおよびlegal-talkに投稿しようと思いますがいかがでしょうか。


> 自身の web 上で公開されている住所は、(敢えて言うなら)
> 二次です。一次情報は、法務局に保管されている情報になるかと思います。詳細は書けませんが、本当は分筆によって住所が変更されているにも関わらず古い住所を発信し続けている事例を知っています。
>
> 自身の web 上で公開されている電話番号は、(敢えて言うなら)
> 二次です。一次情報は、電話会社からの通知です。詳細は書きませんが、ある公立学校にて、自身の web
> 上で誤った電話番号を記した文書を公開しておきながら長期間修正されなかった (そしてその文書以外に電話番号が公開されていないようだった)
> 事例を知っています。
>

この論法だと、現地の掲示にある住所、電話番号も二次情報ということになってしまわないでしょうか。


> 自身の web 上で公開されている座標情報は、(敢えて言うなら)
> 二次です。一次情報は、地物の本当の座標です。詳細は書きませんが、とある超有名企業が自社の店舗の座標を数百mも間違えていた
> (そのため地図表示もデタラメであった) 事例を知っています (私がこの会社に連絡して現在は修正されています)。
>
> 自身の web 上で公開されている営業時間は、(敢えて言うなら) 二次です。一次情報は、実際の店舗の営業時間です。詳細は書きませんが、とある DVD
> 貸し出し店の営業時間が自社 web 上では10時00分からと表記されていたのに実際には毎日9時00分から営業していた事例
> (そしてその1時間の差のために私が数千円の延滞料金を払わされることになった事例) を経験しています。
>

こちらは二次情報でよいと思います。

石野 貴之
yumean1...@gmail.com

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

Re: [OSM-talk] Ways divided by paint?

2019-07-04 Per discussione Warin


On 04/07/19 22:23, Martin Koppenhoefer wrote:


sent from a phone


On 4. Jul 2019, at 11:49, Snusmumriken  wrote:

A painted line that has the legal status of "do not cross" is a
perfectly fine reason to have a separate way.


it doesn’t apply to many people though, for example pedestrians or emergency 
vehicles.


I have seen emergency vehicle cross physical barriers.

So by extension physical barriers should not be mapped. Which would be 
ridiculous.


The definition for a separate highway way is that it implies a separate 
carriageway. We’ve set it like this. IMHO it can hardly put into discussion at 
this point. If you want to map by a different definition, safest would be to 
use a different key.


The definition of 'separation' relies on the local definition?

If there is a need to map barriers that provide emergency use .. then perhaps 
OSM should tag that with a different key.

If there is a requirement to distinguish between barriers of (leagl) paint and 
those of some height .. use the height key for those of some height.
The tag already exists and would provide emergency vehicles with information - 
a highway patrol vehicle may not cross something with height=.2 but a police 
4WD rescue vehicle could.



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

Re: [OSM-talk] Reordering and rewriting Good Practice wiki page

2019-07-04 Per discussione Warin


On 05/07/19 05:54, Jmapb wrote:

On 7/4/2019 12:40 AM, Warin wrote:

On the order of things.

Best to tell them what to do first. This provides some motivation.

Leave 'what not to do' for last, these tend to turn people away.

So I would do:

1    One feature, one OSM element

2    Good changeset comments (+Keep the history)

3    Editing Standards: (Align aerial imagery before tracing, Do not
trace from outdated imagery... Keep straight ways straight ... Mark
estimations with FIXME ... etc.)

4    Do correct errors

5    Verifiability (+Map what's on the ground, Don't map: historic
events, temporary features, local legislation etc)

6    Document your custom-tags (Don't remove tags that you don't
understand...

7    Don't map for the renderer (+ Don't misuse name tag)


I'd personally advocate for one more "don't" -- But it can be phrased as
a "do" if that helps the psychology:

"Try to keep changesets to a manageable size, both in number of changes
and geographical scope."

I believe this is commonly understood best practice, but it's only
vaguely documented.


+1 .. and guilty of it too (in my early days).



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

Re: [OSM-talk-fr] Attribut ref sur les ronds point : la question de Montpellier

2019-07-04 Per discussione Jérôme Amagat

avec un ref=* sur le rond point, pose la question :  est ce que c'est la
référence du rond point ou celle de la route qui la traverse?

le problème de ces référence sur les routes c'est que l'on ne sait pas s'il
faut les voir comme un itinéraire comme les ligne de bus par exemple ou si
c'est plus proche d'un autre nom de rue. A la base je pense que c'est plus
un itinéraire, l'état ou le département gère une route qui va de tel ville
à tel ville en passant part ici, là... et lui donne un nom mais pour la
plupart des gens en local c'est plutôt un autre nom que l'on utilise comme
le nom de la rue.
Dans un cas le rond point fait parti de l'itinéraire, dans l'autre il est à
l’intersection de 2 routes...

si on a un rond point au milieu d'une départementale, une personne qui
traverse le rond point en arrivant d'une route communale et qui s’insère
dans une autre route communale, n'a pas emprunté la départementale mais
dans l'autre sens une personne qui arrive par la départementale et qui va
sur l'autre portion de départementale ne l'a en faite pas quitter...

Mon opinion c'est qu'il faut rien changé, pas de ref sur les rond point par
contre on n'interdit pas les relations type=route route=road pour
représenter les routes départementales (ou nationale ou ...) qui existent
un peu partout en France et qui il me semble comprennent la plupart du
temps les ronds points. Donc si cette métropole a besoin d'avoir le ref sur
les ronds points elle peut utiliser des relations plutôt que des ref=* sur
les way (sans enlevé les ref des way bien sur). Par contre, relation donc
plus dur à maintenir et usage ancien de ref sur les way donc encore plus
dur à maintenir.


Le jeu. 4 juil. 2019 à 20:57,  a écrit :

> D'accord sur la première remarque.
>
> Pas sur la seconde car tu ne mets pas non plus la ref sur chaque nœud du
> reste de la route.
>
> Mettre la ref sur l'ensemble des ways du giratoire (s'il est découpé) mais
> pas sur les nœuds est parfaitement homogène avec les traitements de la
> route.
>
> Il semble normal que les routes par exemple départementales ne soient pas
> coupées en tronçons entre les ronds-points. Que les ref en question
> figurent ou non sur les rond-points, les ronds-points font bien partie de
> la route.
>
> C'est un peu comme lors du passage des routes dans les villes et villages
> : la ref peut apparaître ou pas. Mais logiquement la ref est continue.
>
> Frédéric, si les gens de Montpellier veulent ajouter les ref c'est
> qu'elles existent, pas vrai ?
>
> Jean-Yvon
>
>
> Le 04/07/2019 à 18:23, marc marc - marc_marc_...@hotmail.com a écrit :
>
> avoir ou pas de multiple ref n'est le soucis ref=1;2
>
> le soucis c'est qu'il y a confusion entre un carrefour
> et la route.
> on ne duplique pas la ref de la route sur chaque noeud
> d'un carrefour de cette route, je trouve donc cohérent
> de ne pas dupliquer la ref de la route sur les ronds-point
>
> Le 04.07.19 à 16:19, Frédéric Rodrigo a écrit :
>
> Cela a déjà été discuté et je ne pense pas qu'il y a lieu de changer de
> position.
>
> Certains pays on des ref de carrefours, mais pas la France.
>
> Que faire quand plusieurs routes passant par un carrefour ont des ref ?
>
> Frédéric.
>
>
> Le 03/07/2019 à 11:21, osm.sanspourr...@spamgourmet.com a écrit :
>
> Les versions anglaise et française sont non seulement différentes mais
> explicitement contradictoires :
>
>
> /Ref Tagging/
>
> / 
> /
>
> /Roundabout with ref tagging consistent with connecting roads/
>
> /For roundabouts that have ways either continuing through, or ending
> at the roundabout, //ref 
> =*//and 
> //int_ref 
> =*//tags from those
> ways should be added to that roundabout. This allows routing to
> navigate through the roundabout more fluidly.
> /
>
> et /
> /
>
>   * /Le tag //ref
>  
> =*//n'a pas de
> sens sur un carrefour. Les références désignent les routes et non
> les carrefours, même si une route est coupée par un carrefour
> giratoire, il ne faut pas reporter la référence de cette route sur
> ce chemin./
>
> La version française date de 2011 pour cette partie./
> /
>
> Avant le 9 avril 2019, la page anglaise ne mentionnait pas de ref.
>
> Les modifs correspondantes datent du 9 au 25 avril./
> /
>
> En conclusion je donnerais raison à la personne de Montpellier. Et en
> conséquence entrerais un ticket dans Osmose pour éviter ce signalement.
>
> À mon avis on peut virer tout test de ref sur les rond-points car si
> jamais une route principale commence sur un rond-point, le rond-point
> peut avoir pour référence celle de la route.
>
>

[talk-cz] Rozcestník a bod záchrany, jako jeden nebo dva body?

2019-07-04 Per discussione majka

Jak značit bod záchrany, který je umístěný přímo na rozcestníku? Například
tady 
Dát jako samostatný bod, nebo připojit k bodu rozcestníku?
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-fr] booking=* <> reservation=*

2019-07-04 Per discussione LeTopographeFou

Je pense également que réserver "booking=*" au seul site Booking n'est 
pas souhaitable. Il existe plein d'autres services et on est pas à 
l'abris qu'il y en ai un qui s'appelle "amenity" ou "building". Il 
faudrait à minima l'isoler dans un namespace, "reservation:booking" ou 
même "reservation:url:booking" pour pouvoir différencier différents 
moyens de réservation.


Cependant il serait bon de ne pas résumer le débat à "Booking" mais 
parler de tous les sites de location entre particuliers et, en allant 
plus loin, aux plateformes de réservation de rendez-vous médicaux, de 
soins de beautés, de cours, de billets de train/avion/bus, de courses, 
de restauration, de voiture (y compris entre particuliers type Drivy), 
de places de théatre/cinéma...


Cela dit mettre du Booking dans OSM présente aujourd'hui quelques 
soucis. Je ne suis pas opposé mais je dis 'attention' :


1. Ils n'ont pas de système de clé unique, publique et international
   partageable dans un "ref:booking" et attaquable via API Booking (ce
   qui serait bien plus propre qu'une URL)
2. Leurs URL sont moches, tout le monde ne sait pas les simplifier à
   leur stricte nécessaire en virant les éléments qui ne sont là que
   pour faire du suivi de navigation dans le cadre d'une recherche (ce
   qui n'a plus de sens dès qu'on le met dans OSM)
3. Dans l'URL il y a la langue (du moins quand je consulte un
   hébergement j'ai un '/fr/'), il conviendrait probablement de
   préciser le code ISO dans la clé (sinon un allemand peut se
   retrouver avec un lien en chinois)

Cordialement,

LeTopographeFou

Le 04/07/2019 à 15:29, marc marc a écrit :

Bonjour,

je fais écho ici d'une discussion qui a commencé sur la ml tagging
pour indiquer qu'un POI accepte/refuse/recommande une réservation,
la clef la plus courante est reservation=*
un contributeur avait crée une page booking=* et l'avait
ajout en recommandation sur plusieurs autres pages.
mais outre le fait d'avoir 2 clefs pour la même chose,
cela entrait en conflit avec booking=l'url booking.com
En est arrivé la conclusion de migrer
- booking=* vers reservation=* lorsque concerne la possibilité ou non de
réserver
- garder dans booking=* les url booking
- il y a aussi quelques urls de réservation non booking.
rien n'a été décidé mais sans doute que reservation:website serrait le +
cohérent.

a noter que le plus grand nombre de cas (125) sont des lignes de
train passant par la France. à vos correcteurs, prêt ? partez :D
et si cela ne motive personne, je m'y collerai :)

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

[Talk-Kosovo] (no subject)

2019-07-04 Per discussione Arianit Dobroshi


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

Re: [Talk-GB] Importing NaPTAN Data




4 lip 2019, 19:28 od talk-gb@openstreetmap.org:

> On 04/07/2019 16:39, Martin Wynne wrote:
>
>> On 04/07/2019 16:11, Dave F via Talk-GB wrote:
>>
>>>
>>> In OSM we map *physical* objects only.
>>>
>>
>> In rural areas there are many places where buses are timetabled to stop but 
>> where there is nothing physical -- no signpost or shelter.
>>
>
> These are still 'physical' in the sense that they exist in the timetable & 
> Naptan documents. (Think also boundaries which don't have dashed lines 
> painted across fields)
>
In that sense everything is physical,
boundaries also have paper records
and there are some markers.
>>
>> The wiki for highway says "Can be mapped more rigorously using 
>> public_transport=stop_position for the position where the vehicle stops and 
>> public_transport=platform for the place where passengers wait.
>>
>
> It's disappointing to see, once again, the PT schema developers hi-jacking 
> wiki pages to enforce their schema. The comments column is meant to describe 
> how to use the tag not promote alternatives. This needs changing.
>
Yeah, there is nothing more rigorous
in extremely verbose PTv2 tagging.
> highway=bus_stop is perfectly adequate to locate the place where people wait 
> for a bus. 'platform' is redundant
>
> PTv2 is a complete mess. it needs rescinding.
>
I completely agree here.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Données routières ouvertes en France

2019-07-04 Per discussione osm . sanspourriel

10 % de rues/routes/chemins (en nombre pas en km) sans rapprochement ça
ne veut pas dire qu'elles manquent dans OSM.

Ça peut vouloir dire qu'elles n'ont pas de nom dans OSM.

Là c'est la BANO, donc a priori les voies numérotées.

A-t-on une autre statistique sur les voies non numérotées ?

Je suppose ça nettement moins bon. Par chez moi j'ai pas mal de chemins
d'exploitation sans rapprochement. Mais la plupart de ces chemins sont
dans OSM, juste sans référence.

Et rapprochement difficile à faire sans avoir le positionnement du
chemin depuis http://cadastre.openstreetmap.fr/fantoir
Le cadastre peut aider mais c'est fastidieux.

J'ai regardé un chemin avec positionnement : il est dans OSM mais sans
nom car le chemin de XXX va à XXX, lieu-dit nommé dans OSM dont la
première maison est au bout de 10 m du chemin.

Donc le chemin était dans OSM, sans nom mais sans que ce soit un
problème concret pour l'utilisateur lambda car il y avait XXX sur la carte.
Sur la carte IGN c'est pareil (hameau et chemin sans nom) sauf que le
nom tu le retrouves uniquement au Soundex ;-). Disons que le cadastre et
OSM ont la graphie bretonne et l'IGN comme les Pages-Jaunes (une
réponse) la graphie française.

Ceci dit maintenant c'est corrigé. Sur le terrain il y a juste un
fléchage du hameau, sans nom du chemin affiché.

Dans un autre cas c'est une route devenue une rue de même nom. Là c'est
FANTOIR qui ne semble pas à jour.

Ailleurs ce sont les ZI/ZA/ZAC qui sont considérées comme voies dans
FANTOIR même quand aujourd'hui les voies de ces endroits sont nommés.

Encore une fois : ça peut être suffisant comme ça peut sembler trop
incomplet, ça dépend du besoin du client.

Jean-Yvon

Le 04/07/2019 à 21:16, Vincent de Château-Thierry - osm.v...@free.fr a
écrit :

Oops, ça va mieux avec le lien :
http://munin.openstreetmap.fr/osm12.openstreetmap.fr/osm104.openstreetmap.fr/bano_rapproche.html

(Merci marc_marc)
vincent

Le 04/07/2019, 16:56 "Vincent de Château-Thierry" a
écrit:

Bonjour, > De: "Julien Minet" > > A voir si la complétude des rues
sur OSM est satisfaisante > en France, une idée sur ce point ?
(vaste question, je serai > incapable de répondre pour la
Belgique!) Pour la France on a ce graphique, très plat maintenant
mais qui a beaucoup monté au fil des années, qui confronte les
rues d'OSM au référentiel FANTOIR. On a maintenant plus d'1
million de voies nommées, ce qui ne fait certes pas l'intégralité
mais pas loin. À voir selon ton besoin. vincent
___ Talk-fr mailing
list Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [Talk-GB] Importing NaPTAN Data

2019-07-04 Per discussione ael via Talk-GB

On Thu, Jul 04, 2019 at 06:49:10PM +0100, Dave F via Talk-GB wrote:
> 
> 
> On 04/07/2019 16:59, Silent Spike wrote:
> > 
> > My understanding is that `public_transport=platform` is any place where
> > public transport can be accessed
> 
> Same as bus_stop/tram_stop, you mean?
> 
> > and should not literally be interpreted as
> > a physical platform
> 
> then why hi-jack the word 'platform' which has a clear, specific meaning?
> Yet more confusion
> 
> > If anything `highway=bus_stop` is redundant data,
> 
> It's is a well established, popular tag far exceeding any PT tags
> 
> > however it's necessary
> > for render compatibility (violating the "don't tag for the renderer rule"
> 
> I think your logic got a bit twisted around. bus_stop is the original & no
> PT tag adds anything extra to improve the database.
> 
> > and (in my opinion) should not impede mapping progress.
> 
> Existing tags work, Changing for the sake of change is irrelevant. PTv2
> needs to be rescinded.

+1

ael


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

Re: [OSM-talk-fr] Données routières ouvertes en France

2019-07-04 Per discussione deuzeffe


On 04/07/2019 12:50, Maël REBOUX wrote:


Il y a cependant des collectivités locales qui mettent leur données 
référentielles de voies en open data. Voir sur data.gouv.fr

[ https://www.data.gouv.fr/fr/search/?q=filaire+de+voies | 
https://www.data.gouv.fr/fr/search/?q=filaire+de+voies ]
[ https://www.data.gouv.fr/fr/search/?q=tron%C3%A7ons+voies | 
https://www.data.gouv.fr/fr/search/?q=tron%C3%A7ons+voies ]


Et toutes ne l'y mettent pas :( Par ex. : 
http://catalogue.geo-ide.developpement-durable.gouv.fr/catalogue/srv/fre/catalog.search#/metadata/fr-120066022-jdd-71f0f5e4-c1cc-44ae-9d63-cd50c27591fb


(quelle horreur, cette url :/)
--
deuzeffe

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

Re: [Talk-GB] Importing NaPTAN Data

2019-07-04 Per discussione Martin Wynne


On 04/07/2019 18:51, Dave F via Talk-GB wrote:


These are still 'physical' in the sense that they exist in the timetable 
& Naptan documents. (Think also boundaries which don't have dashed lines 
painted across fields)


This strikes me as a strange definition of "physical" and could cover 
almost anything.


My definition of "physical" is something I can take a photograph of.

But I don't see any reason why OSM should be limited to such "physical" 
objects. Most maps show all sorts of non-physical data.


cheers,

Martin.

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

Re: [OSM-talk] Reordering and rewriting Good Practice wiki page

2019-07-04 Per discussione Jmapb


On 7/4/2019 12:40 AM, Warin wrote:

On the order of things.

Best to tell them what to do first. This provides some motivation.

Leave 'what not to do' for last, these tend to turn people away.

So I would do:

1    One feature, one OSM element

2    Good changeset comments (+Keep the history)

3    Editing Standards: (Align aerial imagery before tracing, Do not
trace from outdated imagery... Keep straight ways straight ... Mark
estimations with FIXME ... etc.)

4    Do correct errors

5    Verifiability (+Map what's on the ground, Don't map: historic
events, temporary features, local legislation etc)

6    Document your custom-tags (Don't remove tags that you don't
understand...

7    Don't map for the renderer (+ Don't misuse name tag)


I'd personally advocate for one more "don't" -- But it can be phrased as
a "do" if that helps the psychology:

"Try to keep changesets to a manageable size, both in number of changes
and geographical scope."

I believe this is commonly understood best practice, but it's only
vaguely documented.

Jason


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

Re: [Talk-it] Mapping campi rom

2019-07-04 Per discussione Andrea Musuruane

Ciao,

On Thu, Jul 4, 2019 at 9:17 PM Francesco Ansanelli 
wrote:

> Buonasera Lista,
>
> vorrei sapere se avete già mappato campi rom e quali tag avete utilizzato.
> Ho fatto alcune ricerche su OSM e condivido l'idea di mettere
> "landuse=residential", es:
> https://www.openstreetmap.org/way/211772563
> https://www.openstreetmap.org/way/338456215
>
> però non mi piace identificarli mediante il mero tag name.
> C'è chi ha messo "residential=halting_site" come suggerito dal Wiki
> francese:
> https://wiki.openstreetmap.org/wiki/Tag:residential%3Dhalting_site
> es:
> https://www.openstreetmap.org/way/595179726
>

Concordo sull'uso di landuse=residential + residential=halting_site.

Ciao,

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

[Talk-it] Mapping campi rom

2019-07-04 Per discussione Francesco Ansanelli

Buonasera Lista,

vorrei sapere se avete già mappato campi rom e quali tag avete utilizzato.
Ho fatto alcune ricerche su OSM e condivido l'idea di mettere
"landuse=residential", es:
https://www.openstreetmap.org/way/211772563
https://www.openstreetmap.org/way/338456215

però non mi piace identificarli mediante il mero tag name.
C'è chi ha messo "residential=halting_site" come suggerito dal Wiki
francese:
https://wiki.openstreetmap.org/wiki/Tag:residential%3Dhalting_site
es:
https://www.openstreetmap.org/way/595179726

Secondo me, è sbagliato in quanto sembra più per i gitani.
Infine, qualcuno deve aver fatto ironia "tourism=attraction"

https://www.openstreetmap.org/node/4971354421

Cosa ne pensate?
Francesco
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Données routières ouvertes en France

2019-07-04 Per discussione Vincent de Château-Thierry

Oops, ça va mieux avec le lien :
http://munin.openstreetmap.fr/osm12.openstreetmap.fr/osm104.openstreetmap.fr/bano_rapproche.html

(Merci marc_marc)
vincent

Le 04/07/2019, 16:56 "Vincent de Château-Thierry"  a écrit:

Bonjour, > De: "Julien Minet" > > A voir si la complétude des rues sur OSM est 
satisfaisante > en France, une idée sur ce point ? (vaste question, je serai > 
incapable de répondre pour la Belgique!) Pour la France on a ce graphique, très 
plat maintenant mais qui a beaucoup monté au fil des années, qui confronte les 
rues d'OSM au référentiel FANTOIR. On a maintenant plus d'1 million de voies 
nommées, ce qui ne fait certes pas l'intégralité mais pas loin. À voir selon 
ton besoin. vincent ___ Talk-fr 
mailing list Talk-fr@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-fr 

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

Re: [OSM-talk-fr] Données routières ouvertes en France

2019-07-04 Per discussione osm . sanspourriel


Christian saura sans doute retrouver les statistiques sur la distance de
l'habitat aux routes (l'INSEE carroie la France pour avoir la densité de
population, normalement à proximité il y a des routes), globalement la
couverture OSM n'est pas mauvaise, il va manquer des rues des
lotissements récents, "récent" étant un concept flou dépendant du nombre
de contributeurs à surveiller le coin ;-).

J'ai ajouté 2 rues hier : j'ai fait une modif dans le coin et j'ai vu
qu'il y avait deux petits nouveaux lotissements par là. Je sais qu'il
doit en manquer d'autres dans ma commune. Et il y a plus de 30 000 communes.

Du coup j'ai jeté un œil sur le Geoportail. Une rue y était, l'autre
manquait.

Alors est-ce que la base IGN est beaucoup meilleure ? Vaut-il mieux
ajouter les routes manquantes dans OSM ou payer l'accès à la base IGN ?

À vous de voir selon le besoin du client. Si c'est du routage, il
manquera potentiellement essentiellement les premiers et derniers mètres.

Je dirais que pour la Belgique, la France ou l'Allemagne, la couverture
est bonne.
Si dans un coin le client juge que la couverture n'est pas suffisante,
il a le droit de contribuer ^^.
Si dans un coin la base IGN n'est pas à jour, il gagne le droit
d'acheter la nouvelle version l'année suivante. Par exemple pour la
route qui ne manque plus sur OSM depuis hier.

Jean-Yvon

Le 04/07/2019 à 12:06, Julien Minet - julien.mi...@champs-libres.coop a
écrit :


Il semble qu'on va devoir utiliser OSM pour ce projet (ben tant
mieux). A voir si la complétude des rues sur OSM est satisfaisante en
France, une idée sur ce point ? (vaste question, je serai incapable de
répondre pour la Belgique!)

Bonne journée,

Julien

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

Re: [OSM-talk-fr] Attribut ref sur les ronds point : la question de Montpellier

2019-07-04 Per discussione osm . sanspourriel


D'accord sur la première remarque.

Pas sur la seconde car tu ne mets pas non plus la ref sur chaque nœud du
reste de la route.

Mettre la ref sur l'ensemble des ways du giratoire (s'il est découpé)
mais pas sur les nœuds est parfaitement homogène avec les traitements de
la route.

Il semble normal que les routes par exemple départementales ne soient
pas coupées en tronçons entre les ronds-points. Que les ref en question
figurent ou non sur les rond-points, les ronds-points font bien partie
de la route.

C'est un peu comme lors du passage des routes dans les villes et
villages : la ref peut apparaître ou pas. Mais logiquement la ref est
continue.

Frédéric, si les gens de Montpellier veulent ajouter les ref c'est
qu'elles existent, pas vrai ?

Jean-Yvon


Le 04/07/2019 à 18:23, marc marc - marc_marc_...@hotmail.com a écrit :

avoir ou pas de multiple ref n'est le soucis ref=1;2

le soucis c'est qu'il y a confusion entre un carrefour
et la route.
on ne duplique pas la ref de la route sur chaque noeud
d'un carrefour de cette route, je trouve donc cohérent
de ne pas dupliquer la ref de la route sur les ronds-point

Le 04.07.19 à 16:19, Frédéric Rodrigo a écrit :

Cela a déjà été discuté et je ne pense pas qu'il y a lieu de changer de
position.

Certains pays on des ref de carrefours, mais pas la France.

Que faire quand plusieurs routes passant par un carrefour ont des ref ?

Frédéric.


Le 03/07/2019 à 11:21, osm.sanspourr...@spamgourmet.com a écrit :

Les versions anglaise et française sont non seulement différentes mais
explicitement contradictoires :


     /Ref Tagging/

//

/Roundabout with ref tagging consistent with connecting roads/

/For roundabouts that have ways either continuing through, or ending
at the roundabout, //ref
=*//and //int_ref
=*//tags from those
ways should be added to that roundabout. This allows routing to
navigate through the roundabout more fluidly.
/

et /
/

   * /Le tag //ref
     =*//n'a pas de
     sens sur un carrefour. Les références désignent les routes et non
     les carrefours, même si une route est coupée par un carrefour
     giratoire, il ne faut pas reporter la référence de cette route sur
     ce chemin./

La version française date de 2011 pour cette partie./
/

Avant le 9 avril 2019, la page anglaise ne mentionnait pas de ref.

Les modifs correspondantes datent du 9 au 25 avril./
/

En conclusion je donnerais raison à la personne de Montpellier. Et en
conséquence entrerais un ticket dans Osmose pour éviter ce signalement.

À mon avis on peut virer tout test de ref sur les rond-points car si
jamais une route principale commence sur un rond-point, le rond-point
peut avoir pour référence celle de la route.

Jean-Yvon

Le 03/07/2019 à 07:45, marc marc - marc_marc_...@hotmail.com a écrit :

Bonjour,

Le 03.07.19 à 00:13, François Lacombe a écrit :

Je vous relaye cette interrogation, postée à bon escient sur le wiki,
par la métropole de Montpellier
https://wiki.openstreetmap.org/wiki/FR_talk:Tag:junction%3Droundabout

je comprend la règle comment étant : "un carrefour est un élément
ponctuel et on ne met pas la ref de la route sur tous les noeuds
de la route"
par extension, on fait pareil avec un "gros carrefour" style
ronds-point.
je saisis pas trop l'argument du guidage gps.
on est perdu si le guidage dit "prenez la 1er sortie du rond-point"
au lieu de "prenez la 1ère sortir du rond-point ref 123 ?"
faudrait par contre aller voir pq c'est pas pareil en fr et anglais.

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

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



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

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

Re: [OSM-talk-fr] Données routières ouvertes en France

Le 04.07.19 à 12:38, Edmond SCOUARNEC a écrit :
> en ce qui concerne les départementales, 
> du Finistère
> A lui de voir s'il peut l'intégrer

qu'est-ce que cela contient en quelques mots ?
quelle fraicheur et/ou fiabilité ?
ces données sont aussi dans osm ?
selon le cas, cela pourrait être interessant de le l'intégrer via osmose

> Osmose 
> avant d'en maîtriser les pré requis.

les pré-requis ne sont pas très élevés :
- avoir contribué "normalement" à osm histoire de maîtriser la base 
(qu'est-ce qu'un noeud, comment on représente un immeuble, comment
on connecte des routes, c'est quoi une clef, une valeur, ...)
- avoir le sens critiques : osmose donne des avis dont il faut
apprécier la pertinence et surtout pas cliquer ok aveuglément.
j'ignore ton niveau dans oms, mais je pense que c'est très accessible.
surtout que tu peux très bien commencer par des rubriques faciles :
par exemple les feux de circulations manquant, l'intégration opendata, 
les objets mapé en double, les voies de parking manquantes, le nom de 
route très semblable, les endroits qui ont un objet avec un nom de rue 
sans avoir cette rue proche, les intersections route<>batiment et 
route<>eau, ...

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

Re: [Talk-GB] Importing NaPTAN Data




In OSM we map *physical* objects only.

What about border - especially
lower administrative units and
nature reserves?


From a previous post:
These are still 'physical' in the sense that they exist in the timetable 
& Naptan documents. (Think also boundaries which don't have dashed lines 
painted across fields)


DaveF

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

Re: [Talk-GB] Importing NaPTAN Data




On 04/07/2019 16:59, Silent Spike wrote:


My understanding is that `public_transport=platform` is any place where
public transport can be accessed


Same as bus_stop/tram_stop, you mean?


and should not literally be interpreted as
a physical platform


then why hi-jack the word 'platform' which has a clear, specific 
meaning? Yet more confusion



If anything `highway=bus_stop` is redundant data,


It's is a well established, popular tag far exceeding any PT tags


however it's necessary
for render compatibility (violating the "don't tag for the renderer rule"


I think your logic got a bit twisted around. bus_stop is the original & 
no PT tag adds anything extra to improve the database.



and (in my opinion) should not impede mapping progress.


Existing tags work, Changing for the sake of change is irrelevant. PTv2 
needs to be rescinded.


DaveF

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

Re: [Talk-GB] Importing NaPTAN Data

This is getting a little bit off topic. I guess to bring things back on
track, would there be any objections to an import along these lines:

   1. Import data specifically for the Aberdeen admin area (ATCO code 639)
   2. Import stops of type BCT ("On-street Bus / Coach / Trolley Stop.")
   3. Import BCT stops of type MKD ("Marked (pole, shelter etc)")
   4. Manually conflate and review the data before upload using JOSM
   5. Split the edits up according to the "LocalityName" data field
   (basically districts from what I can tell)  [or is it better to be one
   changeset for the whole area?]
   6. Tag the stops using:
  - `highway=bus_stop`
  - `public_transport=platform`
  - `bus=yes`
  - `name=*` [Imported]
  - `naptan:AtcoCode=*` [Imported]
  - `naptan:NaptanCode=*` [Imported]
  - `source=naptan`
  - `naptan:verified=no`



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

Re: [Talk-GB] Importing NaPTAN Data


On 04/07/2019 16:39, Martin Wynne wrote:

On 04/07/2019 16:11, Dave F via Talk-GB wrote:


In OSM we map *physical* objects only.


In rural areas there are many places where buses are timetabled to 
stop but where there is nothing physical -- no signpost or shelter.


These are still 'physical' in the sense that they exist in the timetable 
& Naptan documents. (Think also boundaries which don't have dashed lines 
painted across fields)




Are these highway=bus_stop in OSM?


As a guesstimate, if they came from the naptan import, then probably yes



The wiki for highway says "Can be mapped more rigorously using 
public_transport=stop_position for the position where the vehicle 
stops and public_transport=platform for the place where passengers wait.


It's disappointing to see, once again, the PT schema developers 
hi-jacking wiki pages to enforce their schema. The comments column is 
meant to describe how to use the tag not promote alternatives. This 
needs changing.



"public_transport=stop_position for the position where the vehicle stops"
But that's not happening, is it? it's being wastefully duplicated on the 
highway=bus_stop which is most often at the pole/sign location, not on 
the highway.


highway=bus_stop is perfectly adequate to locate the place where people 
wait for a bus. 'platform' is redundant


PTv2 is a complete mess. it needs rescinding.

DaveF

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

Re: [Talk-ca] Problems with tagging of islands/islets in a river

2019-07-04 Per discussione Steffen Roller

I believe I found the problem. The river to the East/South didn't have a
relation "outer" but a member "Grand River: outer". That wasn't the case
for the East/North part.
I changed that.
Now I have to wait and see whether that made a difference.

-st

On Thu, 4 Jul 2019 at 12:39, Steffen Roller 
wrote:

> Hi John,
>
> sounds good.
>
> Question:
> 1. What have you changed? I'd like to learn :-)
> 2. When should the change be visible online?
>
> -st
>
> On Thu, 4 Jul 2019 at 11:20, John Marshall  wrote:
>
>> Done.
>>  Steffen, if I missed any let me know.
>>
>> John
>>
>> On Thu, Jul 4, 2019 at 11:03 AM Clifford Snow 
>> wrote:
>>
>>> Thanks - I'm traveling right now or I would have.
>>>
>>> On Thu, Jul 4, 2019 at 8:01 AM John Marshall  wrote:
>>>
 I will fix it.

 John

 On Thu, Jul 4, 2019 at 10:47 AM Clifford Snow 
 wrote:

> The multipolygon of the river where the islands are missing appears to
> be wrong. JOSM should be able to fix it.
>
> Clifford
>
> On Thu, Jul 4, 2019 at 7:26 AM Steffen Roller <
> steffen.rol...@gmail.com> wrote:
>
>> Rendering of islands/islets in a river
>>
>> I was missing several islands on 'my' Grand River while paddling.
>> I don't understand how to change the attributes of an island in order
>> to get it properly rendered.
>>
>> Have a look at this example:
>> https://www.openstreetmap.org/#map=16/43.3858/-80.3649
>> There are two islands on this map: The one to the West is rendered as
>> I'd expect.
>> The one the East just shows a few symbols for "wood".
>> Looking at the attributes I can't tell the difference. What do I have
>> to change on the Easterly island to make it look like an island once it's
>> rendered?
>>
>> -st
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
>
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>

>>>
>>> --
>>> @osm_washington
>>> www.snowandsnow.us
>>> OpenStreetMap: Maps with a human touch
>>>
>>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-it] Ricerca su musei OSM e statistica ufficiale

2019-07-04 Per discussione Aury88

In effetti nel sito di cui ti ho dato il link vengono conteggiati i musei
etichettati con il tag wikipedia che è diverso dal dire se sono mappati o
meno su OSM...e da quello che ho visto una buona fetta dei musei mappati non
ha il tag wikipedia ... quindi il risultato che hai ottenuto è coerente con
quello indicato nel sito ;-)



-
Ciao,
Aury
--
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: [Talk-ca] Problems with tagging of islands/islets in a river

2019-07-04 Per discussione Steffen Roller

Hi John,

sounds good.

Question:
1. What have you changed? I'd like to learn :-)
2. When should the change be visible online?

-st

On Thu, 4 Jul 2019 at 11:20, John Marshall  wrote:

> Done.
>  Steffen, if I missed any let me know.
>
> John
>
> On Thu, Jul 4, 2019 at 11:03 AM Clifford Snow 
> wrote:
>
>> Thanks - I'm traveling right now or I would have.
>>
>> On Thu, Jul 4, 2019 at 8:01 AM John Marshall  wrote:
>>
>>> I will fix it.
>>>
>>> John
>>>
>>> On Thu, Jul 4, 2019 at 10:47 AM Clifford Snow 
>>> wrote:
>>>
 The multipolygon of the river where the islands are missing appears to
 be wrong. JOSM should be able to fix it.

 Clifford

 On Thu, Jul 4, 2019 at 7:26 AM Steffen Roller 
 wrote:

> Rendering of islands/islets in a river
>
> I was missing several islands on 'my' Grand River while paddling.
> I don't understand how to change the attributes of an island in order
> to get it properly rendered.
>
> Have a look at this example:
> https://www.openstreetmap.org/#map=16/43.3858/-80.3649
> There are two islands on this map: The one to the West is rendered as
> I'd expect.
> The one the East just shows a few symbols for "wood".
> Looking at the attributes I can't tell the difference. What do I have
> to change on the Easterly island to make it look like an island once it's
> rendered?
>
> -st
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>


 --
 @osm_washington
 www.snowandsnow.us
 OpenStreetMap: Maps with a human touch
 ___
 Talk-ca mailing list
 Talk-ca@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-ca

>>>
>>
>> --
>> @osm_washington
>> www.snowandsnow.us
>> OpenStreetMap: Maps with a human touch
>>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-GB] Importing NaPTAN Data



4 lip 2019, 17:11 od talk-gb@openstreetmap.org:

>
> In OSM we map *physical* objects only.
>
What about border - especially 
lower administrative units and 
nature reserves?___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] Ways divided by paint?


4 lip 2019, 15:20 od snusmumriken.map...@runbox.com:

> On Thu, 2019-07-04 at 13:50 +0200, Mateusz Konieczny wrote:
>
>> I strongly disagree with this idea,
>> and multiple times changed such splits
>> back to one way.
>>
>
> I would consider that as an act of vandalism by removing ground truth
> information that your fellow mappers have gathered and encoded in the
> database.
>
I (obviously) add all necessary turn
restrictions.

As result I remove incorrect claim
that road is dual carriageway
without information loss.

And why you consider moving to a 
standard tagging as a vandalism.

On topic of ground truth -
so far in all cases I did after spotting
incorrect mapping during a survey ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Reordering and rewriting Good Practice wiki page

2019-07-04 Per discussione Tobias Knerr

On 04.07.19 05:53, Joseph Eisenberg wrote:
> 2 Verifiability (+Map what's on the ground, Don't map: historic
> events, temporary features, local legislation etc)

In my opinion, the practices that you've turned into subheadings of the
verifiability section are not merely special cases of verifiability.

For example, temporary features are perfectly verifiable (until they
cease to exist, of course). The reasons why it's not usually considered
good practice to map them include the unsustainable maintenance effort
and the impact on offline use of our data.

So I feel these items are really their own separate practices, not part
of verifiability. If you want to avoid having too many top-level
headings, you might still be able to group the three "Don't map..."
rules into a common section.

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

Re: [Talk-lv] Rescuing tree import in Valmiera made by Pēteris Brūns

2019-07-04 Per discussione liste DOT girarsi AT posteo DOT eu


Fundamental and initial problem:
 what is the license of this data?
4 lip 2019, 16:06 od ric...@nakts.net:

> On 03.07.19 12:37, Peteris Bruns wrote:
>
>> Hi,
>>
>> mainly all I can explain was done already answering to Michael at this
>> thread 
>> https://www.openstreetmap.org/changeset/57269387#map=14/57.5362/25.4167
>>
>> In general, I'm now not ready to check all steps required by import
>> procedure. Feel free to delete/revert changesets.
>>
>
> Data quality wise, what other problems exist besides the excess hyphen?___
Talk-lv mailing list
Talk-lv@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lv

Re: [Talk-it] Sempre a proposito di opere "monumentali"

Il 04/07/19 16:45, demon_box ha scritto:
> come devo mappare secondo voi una costruzione del genere?
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> grazie
> 
> --enrico
> 
> 

Un monumento no, ma qualcosa di storico sì, solo non so come viene
definita questo tipo di entrata romana, con colonne e copertura in pietra.




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

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

Re: [OSM-talk-fr] Attribut ref sur les ronds point : la question de Montpellier

avoir ou pas de multiple ref n'est le soucis ref=1;2

le soucis c'est qu'il y a confusion entre un carrefour
et la route.
on ne duplique pas la ref de la route sur chaque noeud
d'un carrefour de cette route, je trouve donc cohérent
de ne pas dupliquer la ref de la route sur les ronds-point

Le 04.07.19 à 16:19, Frédéric Rodrigo a écrit :
> Cela a déjà été discuté et je ne pense pas qu'il y a lieu de changer de 
> position.
> 
> Certains pays on des ref de carrefours, mais pas la France.
> 
> Que faire quand plusieurs routes passant par un carrefour ont des ref ?
> 
> Frédéric.
> 
> 
> Le 03/07/2019 à 11:21, osm.sanspourr...@spamgourmet.com a écrit :
>>
>> Les versions anglaise et française sont non seulement différentes mais 
>> explicitement contradictoires :
>>
>>
>>     /Ref Tagging/
>>
>> // 
>>
>> /Roundabout with ref tagging consistent with connecting roads/
>>
>> /For roundabouts that have ways either continuing through, or ending 
>> at the roundabout, //ref 
>> =*//and //int_ref 
>> =*//tags from those 
>> ways should be added to that roundabout. This allows routing to 
>> navigate through the roundabout more fluidly.
>> /
>>
>> et /
>> /
>>
>>   * /Le tag //ref
>>     =*//n'a pas de
>>     sens sur un carrefour. Les références désignent les routes et non
>>     les carrefours, même si une route est coupée par un carrefour
>>     giratoire, il ne faut pas reporter la référence de cette route sur
>>     ce chemin./
>>
>> La version française date de 2011 pour cette partie./
>> /
>>
>> Avant le 9 avril 2019, la page anglaise ne mentionnait pas de ref.
>>
>> Les modifs correspondantes datent du 9 au 25 avril./
>> /
>>
>> En conclusion je donnerais raison à la personne de Montpellier. Et en 
>> conséquence entrerais un ticket dans Osmose pour éviter ce signalement.
>>
>> À mon avis on peut virer tout test de ref sur les rond-points car si 
>> jamais une route principale commence sur un rond-point, le rond-point 
>> peut avoir pour référence celle de la route.
>>
>> Jean-Yvon
>>
>> Le 03/07/2019 à 07:45, marc marc - marc_marc_...@hotmail.com a écrit :
>>> Bonjour,
>>>
>>> Le 03.07.19 à 00:13, François Lacombe a écrit :
 Je vous relaye cette interrogation, postée à bon escient sur le wiki,
 par la métropole de Montpellier
 https://wiki.openstreetmap.org/wiki/FR_talk:Tag:junction%3Droundabout
>>> je comprend la règle comment étant : "un carrefour est un élément
>>> ponctuel et on ne met pas la ref de la route sur tous les noeuds
>>> de la route"
>>> par extension, on fait pareil avec un "gros carrefour" style 
>>> ronds-point.
>>> je saisis pas trop l'argument du guidage gps.
>>> on est perdu si le guidage dit "prenez la 1er sortie du rond-point"
>>> au lieu de "prenez la 1ère sortir du rond-point ref 123 ?"
>>> faudrait par contre aller voir pq c'est pas pareil en fr et anglais.
>>>
>>> Cordialement,
>>> Marc
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Traduire le wiki ?

Le 04.07.19 à 17:39, Julien Lepiller a écrit :
> À la fin du tableau il y a en petit un lien « La traduction en français peut 
> être éditée ici ». C'est pas plutôt ça ?

Tu as raison, ce template a encore la liste de toutes les traductions 
dupliqué en dur dans le template :(
j'ai fais la traduction dans le template et sur la page du tag lui-même

voici un exemple de page qui évite cette double traduction :
https://wiki.openstreetmap.org/w/index.php?title=FR:Key:valve=edit

la ligne
{{Taglist|tags=valve=butterfly,globe,ball,plug,gate,needle,spool|with_count=true|lang=fr}}
récupère automatiquement la traduction faite sur toutes ces pages au 
lieu de devoir la dupliquer dans la page globale
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Importing NaPTAN Data

2019-07-04 Per discussione Andy Townsend


On 04/07/2019 16:39, Martin Wynne wrote:
In rural areas there are many places where buses are timetabled to 
stop but where there is nothing physical -- no signpost or shelter.


Are these highway=bus_stop in OSM?


(following a previous discussion on this list) I've used 
"physically_present=no" on one of those - after verifying that buses 
actually stop there. Example:


https://www.openstreetmap.org/node/502390265

Best Regards,

Andy



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

[OSM-ja] 名称の次数と住所の次数

2019-07-04 Per discussione Talk-ja 経由

こんにちは、奈良の石川です。

すでに talk-ja でなく talk に場を移してしまったかも知れませんが、私が talk-ja 
しか購読していないので、ここに書かせて下さい。(反応が遅くてすみません。)

 「ウェブサイト上の店名、住所、電話番号など」について話題に挙がっていますが、これらは data source 
からの次数が異なりますので、分けて考えていただきたいです。

店名や支店名といった名称は、所有者自身が命名し、現地でも自身の web 
上でも自身でその名称を広めようとしています。これは、どちらも一次と呼べると思います。「北干住駅」騒動などは、現地以外で正しい情報を発信していたからこそ修正されたものであり、もし自身の
 web 上の情報が一次と呼べないなら修正されることはありません。

自身の web 上で公開されている住所は、(敢えて言うなら) 
二次です。一次情報は、法務局に保管されている情報になるかと思います。詳細は書けませんが、本当は分筆によって住所が変更されているにも関わらず古い住所を発信し続けている事例を知っています。

自身の web 上で公開されている電話番号は、(敢えて言うなら) 二次です。一次情報は、電話会社からの通知です。詳細は書きませんが、ある公立学校にて、自身の 
web 上で誤った電話番号を記した文書を公開しておきながら長期間修正されなかった (そしてその文書以外に電話番号が公開されていないようだった) 
事例を知っています。

自身の web 上で公開されている座標情報は、(敢えて言うなら) 
二次です。一次情報は、地物の本当の座標です。詳細は書きませんが、とある超有名企業が自社の店舗の座標を数百mも間違えていた 
(そのため地図表示もデタラメであった) 事例を知っています (私がこの会社に連絡して現在は修正されています)。

自身の web 上で公開されている営業時間は、(敢えて言うなら) 二次です。一次情報は、実際の店舗の営業時間です。詳細は書きませんが、とある DVD 
貸し出し店の営業時間が自社 web 上では10時00分からと表記されていたのに実際には毎日9時00分から営業していた事例 
(そしてその1時間の差のために私が数千円の延滞料金を払わされることになった事例) を経験しています。

これまでの議論では全て「事実情報」として扱われていましたが、区別する方がよいかと思います。

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

Re: [Talk-GB] Importing NaPTAN Data

On Thu, Jul 4, 2019 at 4:40 PM Martin Wynne  wrote:

> In rural areas there are many places where buses are timetabled to stop
> but where there is nothing physical -- no signpost or shelter.
>
> Are these highway=bus_stop in OSM?
>
> The wiki for highway says "Can be mapped more rigorously using
> public_transport=stop_position for the position where the vehicle stops
> and public_transport=platform for the place where passengers wait.
>

I believe such stops would just be mapped with stop positions. However, I
don't intend to import them currently as I'd need to look into that more
in-depth (and want to keep things simple for now). Just getting the
physical stops imported seems like a good first step which would have the
most significant improvement on available data in OSM.

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

Re: [Talk-GB] Importing NaPTAN Data

On Thu, Jul 4, 2019 at 4:10 PM Dave F via Talk-GB 
wrote:

>
> Please, please don't use public_transport=platform unless you're
> actually mapping an actual, physical, raised object, similar to railway
> platforms.
>
> It has now been regressed one stage further, being superfluously added
> to highway=bus_stop nodes. So much of the PT schema is just duplicating
> valid, existing data which leads to confusion & errors. It is a waste of
> time & effort.
>

My understanding is that `public_transport=platform` is any place where
public transport can be accessed and should not literally be interpreted as
a physical platform (tags not literally matching what they are used to map
seem to be very common in OSM). I think if you want to constructively
change tagging practise you need to discuss it on the tagging list and that
the import I would like to do should follow established tagging.

If anything `highway=bus_stop` is redundant data, however it's necessary
for render compatibility (violating the "don't tag for the renderer rule",
but everyone does it because default render still doesn't support PTv2
scheme).

Until the wider OSM community establishes better methods of tag creation
and deprecation these issues will continually crop up and (in my opinion)
should not impede mapping progress.

> ___
> 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] Traduire le wiki ?

2019-07-04 Per discussione Dlareg

Le 04/07/2019 à 17:39, Julien Lepiller a écrit :
> À la fin du tableau il y a en petit un lien « La traduction en français peut 
> être éditée ici ». C'est pas plutôt ça ?

Je pensais plutôt à ça également

Librement
-- 
Dlareg



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

Re: [OSM-talk-fr] Traduire le wiki ?

2019-07-04 Per discussione Julien Lepiller

Le 4 juillet 2019 15:33:17 GMT+02:00, marc marc  a 
écrit :
>Le 04.07.19 à 15:27, Vincent Bergeot a écrit :
>> https://wiki.openstreetmap.org/wiki/FR:Key:shop#Autres
>> shop=pest_control
>> j'ai voulu traduire la description dans le tableau
>
>si cela n'a pas changé récement, le tableau reprend
>les intitulés des pages de chaque tag via taginfo.
>donc la traduction se fait sur
>https://wiki.openstreetmap.org/wiki/FR:Tag:shop%3Dpest_control
>
>Ensuite la nuit taginfo met à jour sa base et cela devrait
>être à jour dans le tableau du wiki au petit matin.
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

À la fin du tableau il y a en petit un lien « La traduction en français peut 
être éditée ici ». C'est pas plutôt ça ?

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

Re: [Talk-GB] Importing NaPTAN Data

2019-07-04 Per discussione Martin Wynne


On 04/07/2019 16:11, Dave F via Talk-GB wrote:


In OSM we map 
*physical* objects only.


In rural areas there are many places where buses are timetabled to stop 
but where there is nothing physical -- no signpost or shelter.


Are these highway=bus_stop in OSM?

The wiki for highway says "Can be mapped more rigorously using 
public_transport=stop_position for the position where the vehicle stops 
and public_transport=platform for the place where passengers wait.


cheers,

Martin.

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

Re: [Talk-ca] Problems with tagging of islands/islets in a river

2019-07-04 Per discussione John Marshall

Done.
 Steffen, if I missed any let me know.

John

On Thu, Jul 4, 2019 at 11:03 AM Clifford Snow 
wrote:

> Thanks - I'm traveling right now or I would have.
>
> On Thu, Jul 4, 2019 at 8:01 AM John Marshall  wrote:
>
>> I will fix it.
>>
>> John
>>
>> On Thu, Jul 4, 2019 at 10:47 AM Clifford Snow 
>> wrote:
>>
>>> The multipolygon of the river where the islands are missing appears to
>>> be wrong. JOSM should be able to fix it.
>>>
>>> Clifford
>>>
>>> On Thu, Jul 4, 2019 at 7:26 AM Steffen Roller 
>>> wrote:
>>>
 Rendering of islands/islets in a river

 I was missing several islands on 'my' Grand River while paddling.
 I don't understand how to change the attributes of an island in order
 to get it properly rendered.

 Have a look at this example:
 https://www.openstreetmap.org/#map=16/43.3858/-80.3649
 There are two islands on this map: The one to the West is rendered as
 I'd expect.
 The one the East just shows a few symbols for "wood".
 Looking at the attributes I can't tell the difference. What do I have
 to change on the Easterly island to make it look like an island once it's
 rendered?

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

>>>
>>>
>>> --
>>> @osm_washington
>>> www.snowandsnow.us
>>> OpenStreetMap: Maps with a human touch
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>
>
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-gb-westmidlands] Tonight's meeting

2019-07-04 Per discussione Brian Prangle

Hi everyone
I'llbe surveying the industrial estate behind Morrisons Buntsford Park Road

Rgds

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

Re: [Talk-GB] Importing NaPTAN Data

2019-07-04 Per discussione Brian Prangle

 naptan:verified=no dates back to the original import in 2009 and was there
to indicate the bus stop needed surveying to verify its position- when a
survey was done the process was for this tag to be deleted. Might be good
to adopt this process here too?

Regards

Brian

On Thu, 4 Jul 2019 at 16:10, Dave F via Talk-GB 
wrote:

>
> Please, please don't use public_transport=platform unless you're
> actually mapping an actual, physical, raised object, similar to railway
> platforms.
>
> 'platform' has been misappropriated from the physical railway=platform
> by those who developed the PT schema to mean an arbitrary area of
> pavement that's somewhere, roughly near where a bus stops. In OSM we map
> *physical* objects only.
>
> It has now been regressed one stage further, being superfluously added
> to highway=bus_stop nodes. So much of the PT schema is just duplicating
> valid, existing data which leads to confusion & errors. It is a waste of
> time & effort.
>
> --
>
> if you're adding the bus stop & your source is naptan how can
> naptan:verified=no?
>
> DaveF
>
>
> On 02/07/2019 11:06, Ed Loach wrote:
> > David wrote:
> >
> >> Given that few people like maintenance work, if you can't map all
> >> the
> >> stops from first principles, it is very unlikely that imported ones will
> >> get maintained.  Retaining the NaPTAN tagging is important in
> >> allowing
> >> any later remerge of the updated NaPTAN data.
> > I've been regularly updating local bus route relations (all now upgraded
> to PT schema v2) in Tendring [1], Colchester [1] and Maldon [2] areas of
> Essex. This involves more maintenance than just the bus stops (which for
> Essex were imported some years ago). I've written a program to help me with
> this, comparing the opendata with the OSM data so I can work out what needs
> updating.
> >
> > Occasionally I encounter a bus stop used by a bus route which wasn't
> imported previously. In these cases I add the stop from NaPTAN (based on
> their latitude and longitude) and add the tags:
> > highway=bus_stop
> > public_transport=platform
> > source=naptan
> > naptan:verified=no
> > name=(NaPTAN name)
> > naptan:AtcoCode=(whatever)
> > naptan:NaptanCode=(whatever)
> >
> > If the bus stop type is not MKD I add
> >
> > naptan:BusStopType=(bus stop type)
> >
> > and if the status is not "act" I add
> >
> > naptan:Status=(status)
> >
> > This last one is very rare as I think it is only once that I've found a
> deleted bus stop still part of a bus route (the road had been diverted and
> new stops installed - the old stop was on what is now a cycle path).
> >
> >> Another problem with NaPTAN stops, which applies to non-OSM
> >> users as
> >> well is that they have virtual stops in Hail and Ride areas.  Routers
> >> seem to only like people boarding at those place, so, in my case, can
> >> take me about 7 minutes out of my way against the direction of
> >> travel,
> >> so tell me I have missed a bus that could be easily caught.
> > I'll agree with this. I've been adding them at the NaPTAN location as
> described above if they aren't already in, but these are occasionally up
> cul-de-sacs (usually at the start or end of the route).
> >
> > Ed
> >
> > [1] https://wiki.openstreetmap.org/wiki/Tendring(Essex)/Bus_Routes
> > [2]
> https://wiki.openstreetmap.org/wiki/Maldon(Essex_District)/Bus_Routes
> >
> >
> >
> > ---
> > This email has been checked for viruses by Avast antivirus software.
> > https://www.avast.com/antivirus
> >
> >
> > ___
> > Talk-GB mailing list
> > Talk-GB@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-gb
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Importing NaPTAN Data



Please, please don't use public_transport=platform unless you're 
actually mapping an actual, physical, raised object, similar to railway 
platforms.


'platform' has been misappropriated from the physical railway=platform 
by those who developed the PT schema to mean an arbitrary area of 
pavement that's somewhere, roughly near where a bus stops. In OSM we map 
*physical* objects only.


It has now been regressed one stage further, being superfluously added 
to highway=bus_stop nodes. So much of the PT schema is just duplicating 
valid, existing data which leads to confusion & errors. It is a waste of 
time & effort.


--

if you're adding the bus stop & your source is naptan how can 
naptan:verified=no?


DaveF


On 02/07/2019 11:06, Ed Loach wrote:

David wrote:


Given that few people like maintenance work, if you can't map all
the
stops from first principles, it is very unlikely that imported ones will
get maintained.  Retaining the NaPTAN tagging is important in
allowing
any later remerge of the updated NaPTAN data.

I've been regularly updating local bus route relations (all now upgraded to PT 
schema v2) in Tendring [1], Colchester [1] and Maldon [2] areas of Essex. This 
involves more maintenance than just the bus stops (which for Essex were 
imported some years ago). I've written a program to help me with this, 
comparing the opendata with the OSM data so I can work out what needs updating.

Occasionally I encounter a bus stop used by a bus route which wasn't imported 
previously. In these cases I add the stop from NaPTAN (based on their latitude 
and longitude) and add the tags:
highway=bus_stop
public_transport=platform
source=naptan
naptan:verified=no
name=(NaPTAN name)
naptan:AtcoCode=(whatever)
naptan:NaptanCode=(whatever)

If the bus stop type is not MKD I add

naptan:BusStopType=(bus stop type)

and if the status is not "act" I add

naptan:Status=(status)

This last one is very rare as I think it is only once that I've found a deleted 
bus stop still part of a bus route (the road had been diverted and new stops 
installed - the old stop was on what is now a cycle path).
  

Another problem with NaPTAN stops, which applies to non-OSM
users as
well is that they have virtual stops in Hail and Ride areas.  Routers
seem to only like people boarding at those place, so, in my case, can
take me about 7 minutes out of my way against the direction of
travel,
so tell me I have missed a bus that could be easily caught.

I'll agree with this. I've been adding them at the NaPTAN location as described 
above if they aren't already in, but these are occasionally up cul-de-sacs 
(usually at the start or end of the route).

Ed

[1] https://wiki.openstreetmap.org/wiki/Tendring(Essex)/Bus_Routes
[2] https://wiki.openstreetmap.org/wiki/Maldon(Essex_District)/Bus_Routes



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


___
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-cz] Drobnosti na osmap.cz

2019-07-04 Per discussione Tom Ka

On Wed, Jul 3, 2019, 15:52 Petr Vozdecký  wrote:

> ahoj,
> hlasim poznatky po upravach ikon vrstvy fotek Fody:
> - když je rozcestník "pěší" + "cyklo" + "lyžařský", tak se zobrazí vždy
> ikonka pěší+lyžařský. Návrh: protože asi již složitějšáí kombinace v praxi
> neexistuje (leda ještě + vozíčkářská trasa?), tak tomu věnovat speciální
> ikonu, např. horní šipku udělat z části oranžovou a z části žlutou (pokud
> bude očima patrný rozdíl)
>

pri pokusech too nebylo pouzitelne, proto jsem to nedelal,  ale zdroj je na
githubu, mas moznost se umelecky projevit...

- ještě prosím o speciální ikony pro chybějící information=board a
> information=map - pak se bude dát (konečně!) opravdu jednoduše najít, co
> kde chybí vyfocené!
>

Je v planu jak bude chvili cas.

- vyšší dívčí by byla u vrstvy OsmHiCheck možnost zapínat subvrstvy
> (chybějící rozcestníky zvlášť od mapy a boardů)
>

Bylo by fajn pro obe vrstvy ale je dost netrivialni. Marian se na to
psychicky pripravuje. Muzes mu poslat stene neceho peniveho jako podporu
motivace, adresu dodam :-)

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

Re: [Talk-ca] Problems with tagging of islands/islets in a river

2019-07-04 Per discussione Clifford Snow

Thanks - I'm traveling right now or I would have.

On Thu, Jul 4, 2019 at 8:01 AM John Marshall  wrote:

> I will fix it.
>
> John
>
> On Thu, Jul 4, 2019 at 10:47 AM Clifford Snow 
> wrote:
>
>> The multipolygon of the river where the islands are missing appears to be
>> wrong. JOSM should be able to fix it.
>>
>> Clifford
>>
>> On Thu, Jul 4, 2019 at 7:26 AM Steffen Roller 
>> wrote:
>>
>>> Rendering of islands/islets in a river
>>>
>>> I was missing several islands on 'my' Grand River while paddling.
>>> I don't understand how to change the attributes of an island in order to
>>> get it properly rendered.
>>>
>>> Have a look at this example:
>>> https://www.openstreetmap.org/#map=16/43.3858/-80.3649
>>> There are two islands on this map: The one to the West is rendered as
>>> I'd expect.
>>> The one the East just shows a few symbols for "wood".
>>> Looking at the attributes I can't tell the difference. What do I have to
>>> change on the Easterly island to make it look like an island once it's
>>> rendered?
>>>
>>> -st
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>
>>
>> --
>> @osm_washington
>> www.snowandsnow.us
>> OpenStreetMap: Maps with a human touch
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>

-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Problems with tagging of islands/islets in a river

2019-07-04 Per discussione John Marshall

I will fix it.

John

On Thu, Jul 4, 2019 at 10:47 AM Clifford Snow 
wrote:

> The multipolygon of the river where the islands are missing appears to be
> wrong. JOSM should be able to fix it.
>
> Clifford
>
> On Thu, Jul 4, 2019 at 7:26 AM Steffen Roller 
> wrote:
>
>> Rendering of islands/islets in a river
>>
>> I was missing several islands on 'my' Grand River while paddling.
>> I don't understand how to change the attributes of an island in order to
>> get it properly rendered.
>>
>> Have a look at this example:
>> https://www.openstreetmap.org/#map=16/43.3858/-80.3649
>> There are two islands on this map: The one to the West is rendered as I'd
>> expect.
>> The one the East just shows a few symbols for "wood".
>> Looking at the attributes I can't tell the difference. What do I have to
>> change on the Easterly island to make it look like an island once it's
>> rendered?
>>
>> -st
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
>
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
> ___
> 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] Nome linea elettrica che cambia

scratera wrote
> ..dubito che unireti si interessi di distribuzione a 130.000 kv...si
> fermna
> alla rete 20KV per il resto è terna ad occuparsi del 130.000 sul
> territorio
> nazionale

dici? se ne sei certo allora è così, in effetti non è assolutamente semplice
districarsi in questo tipo di informazioni se non si è del settore

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: [talk-cz] Drobnosti na osmap.cz

2019-07-04 Per discussione Tom Ka

Ahoj, tagovat co je na fotce, to jedine se pak da zpetne overit bez
problemu. Z hlediska kontrol OsmHiCheck je to asi jedno pokud dane fotky
existuji.

Bye

On Wed, Jul 3, 2019, 10:37 majkaz  wrote:

> Hlavně pro Toma jeden drobný dotaz k fotkám rozcestníků a jejich tagování:
>
> Mám brát rozcestník jako celek (tedy v podstatě součet všech cedulí) nebo
> označovat každou fotku samostatně podle toho, co na ní vidím?
> Konkrétně: Pokud je na rozcestníku značení turistické, cyklo + lyžařské,
> mám všechny fotky označit takhle, nebo podle toho, co je na konkrétní
> fotce? V důsledku by tedy byla jedna fotka např. pěší + lyže, druhá jen
> cyklo atd. Zatím volím ten druhý způsob, ale není mi jasné, čemu se dává
> přednost.
>
> Majka
>
> ___
> 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: [OSM-talk] Ways divided by paint?

2019-07-04 Per discussione Snusmumriken

On Thu, 2019-07-04 at 13:44 +, Philip Barnes wrote:
> On Thursday, 4 July 2019, Snusmumriken wrote:
> > On Thu, 2019-07-04 at 13:50 +0200, Mateusz Konieczny wrote:
> > > I strongly disagree with this idea,
> > > and multiple times changed such splits
> > > back to one way.
> > 
> > I would consider that as an act of vandalism by removing ground
> > truth
> > information that your fellow mappers have gathered and encoded in
> > the
> > database.
> > 
> It is only vandalism if you loose information, if you are improving
> the mapping by changing such misleading information to correctly
> mapped turn lanes then it is improving the map.

Turn lane tagging is great and it certainly has its place osm mapping.
But in my experience of mapping it cannot replace the need to sometimes
split ways at a legal barrier to get a complete picture of how the
traffic can legally flow and thus provide a relevant routing
suggestion.


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

Re: [OSM-talk-fr] Données routières ouvertes en France

2019-07-04 Per discussione Vincent de Château-Thierry

Bonjour,

> De: "Julien Minet" 
> 
> A voir si la complétude des rues sur OSM est satisfaisante
> en France, une idée sur ce point ? (vaste question, je serai
> incapable de répondre pour la Belgique!)

Pour la France on a ce graphique, très plat maintenant mais qui a beaucoup 
monté au fil des années, qui confronte les rues d'OSM au référentiel FANTOIR. 
On a maintenant plus d'1 million de voies nommées, ce qui ne fait certes pas 
l'intégralité mais pas loin. À voir selon ton besoin.

vincent

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

Re: [Talk-it] Sempre a proposito di opere "monumentali"

...aggiungo che si tratta di una specie di portale di entrata ad uno Stadio
Militare.
oggi non si entra più da lì ma lateralmente ed è diventato parco pubblico.

--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: [Talk-it] Nome linea elettrica che cambia

2019-07-04 Per discussione scratera

..dubito che unireti si interessi di distribuzione a 130.000 kv...si fermna
alla rete 20KV per il resto è terna ad occuparsi del 130.000 sul territorio
nazionale



--
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] Ways divided by paint?

2019-07-04 Per discussione Lester Caine


On 04/07/2019 15:24, Mike N wrote:
What if strictly following the rule of "no split ways unless physical 
divider" results in wildly incorrect turn-by-turn instructions?


I have the same problem with the right turn lane being removed from 
https://www.openstreetmap.org/#map=19/52.11366/-1.94141 ... one can 
transition from the A46 to the A44 heading north WITHOUT having to stop 
for the roundabout. Because the only separation IS a crosshatch area the 
slip road has been removed but there is NOTHING to indicate that this 
slip road even exists by any other tagging! Unless someone has an 
'approved' way of adding it back?


Personally I think that micro-mapping complex junctions does require 
multiple ways even if the planned routes through a junction can be 
abused by taking the wrong path ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-ca] Problems with tagging of islands/islets in a river

2019-07-04 Per discussione Clifford Snow

The multipolygon of the river where the islands are missing appears to be
wrong. JOSM should be able to fix it.

Clifford

On Thu, Jul 4, 2019 at 7:26 AM Steffen Roller 
wrote:

> Rendering of islands/islets in a river
>
> I was missing several islands on 'my' Grand River while paddling.
> I don't understand how to change the attributes of an island in order to
> get it properly rendered.
>
> Have a look at this example:
> https://www.openstreetmap.org/#map=16/43.3858/-80.3649
> There are two islands on this map: The one to the West is rendered as I'd
> expect.
> The one the East just shows a few symbols for "wood".
> Looking at the attributes I can't tell the difference. What do I have to
> change on the Easterly island to make it look like an island once it's
> rendered?
>
> -st
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>


-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-it] Sempre a proposito di opere "monumentali"

come devo mappare secondo voi una costruzione del genere?


 


 


 


 

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: [Talk-GB] Importing NaPTAN Data

2019-07-04 Per discussione Brian Prangle

It's also useful to add

shelter=yes if there is one
route_ref= x;y  indicating bus route nos that stop there (if indicated on
the stop)
CUS stops are also useful to add but omitting the highway=bus-stop tag (
you can always add the public tranpsort stop_poisition as a node on the
highway). They often become marked with pole over time
There's also a relatively new tag to indicate if the bus stop allows the
bus to pull in to a small layby off the main highway (but I've forgotten
what it is)

Your local bus authority might also be able to help (in the West Mids TfWM
have been very helpful)

Personally I've given up on bus route relations: they're a time sink in
editing them in the first place and they're even more of a time sink to
maintain. I think they're better off in a separate layer in dedicated
journey planners maintained by public transport authorities.

Regards

Brian

Regards

Brian

On Thu, 4 Jul 2019 at 14:54, Silent Spike  wrote:

> On Tue, Jul 2, 2019 at 11:07 AM Ed Loach  wrote:
>
>> highway=bus_stop
>> public_transport=platform
>> source=naptan
>> naptan:verified=no
>> name=(NaPTAN name)
>> naptan:AtcoCode=(whatever)
>> naptan:NaptanCode=(whatever)
>>
>> If the bus stop type is not MKD I add
>>
>> naptan:BusStopType=(bus stop type)
>>
>> and if the status is not "act" I add
>>
>> naptan:Status=(status)
>>
>
> These tags all seem reasonable to import to me. Would be curious to learn
> more about your route maintenance process. I have a list of local bus route
> relations I've been meaning to update, but it's hard to do so without all
> of the stops mapped (hence my desire to import the available data).
>
>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-it] Nome linea elettrica che cambia

2019-07-04 Per discussione Jack Armstrong dan...@sprynet.com

scratera wrote
> ..dai cartelli posizionati operatore però e ASM

ASM da un paio d'anni per quanto riguarda la rete elettrica è diventata
Unareti S.p.a.
ciao

--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] Ways divided by paint?

If mappers are permitted to create numerous new ways based solely on a painted 
surface, intersections will become completely choked with lanes and will become 
unmanageable.

In the given example, turns were already permitted prior to the additional 
superfluous lanes being added. This creates confusion and unnecessary clutter 
and should not be encouraged. The intersection was fine before the addition of 
the highway links. The new links add nothing to the map other than clutter.

https://www.openstreetmap.org/edit?changeset=70997250#map=20/39.57344/-104.98491

- chachafish

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

[Talk-ca] Problems with tagging of islands/islets in a river

2019-07-04 Per discussione Steffen Roller

Rendering of islands/islets in a river

I was missing several islands on 'my' Grand River while paddling.
I don't understand how to change the attributes of an island in order to
get it properly rendered.

Have a look at this example:
https://www.openstreetmap.org/#map=16/43.3858/-80.3649
There are two islands on this map: The one to the West is rendered as I'd
expect.
The one the East just shows a few symbols for "wood".
Looking at the attributes I can't tell the difference. What do I have to
change on the Easterly island to make it look like an island once it's
rendered?

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

Re: [OSM-talk] Ways divided by paint?

2019-07-04 Per discussione Mike N


On 7/4/2019 7:50 AM, Mateusz Konieczny wrote:

I strongly disagree with this idea,
and multiple times changed such splits
back to one way.



  What if strictly following the rule of "no split ways unless physical 
divider" results in wildly incorrect turn-by-turn instructions?  For 
example -


https://www.openstreetmap.org/#map=19/34.93102/-82.32703

  Traveling SouthEast on Reid School Road and transitioning to Edwards 
Mill Road; there's no divider and this rule would remove the short 1-way 
link.   Turn by Turn instructions would change from "Bear slight 
right..."  to "turn right, then left at the stop sign".


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

Re: [OSM-talk-fr] Attribut ref sur les ronds point : la question de Montpellier

2019-07-04 Per discussione Frédéric Rodrigo

Cela a déjà été discuté et je ne pense pas qu'il y a lieu de changer de 
position.


Certains pays on des ref de carrefours, mais pas la France.

Que faire quand plusieurs routes passant par un carrefour ont des ref ?

Frédéric.


Le 03/07/2019 à 11:21, osm.sanspourr...@spamgourmet.com a écrit :


Les versions anglaise et française sont non seulement différentes mais 
explicitement contradictoires :



/Ref Tagging/

// 


/Roundabout with ref tagging consistent with connecting roads/

/For roundabouts that have ways either continuing through, or ending 
at the roundabout, //ref 
=*//and //int_ref 
=*//tags from those 
ways should be added to that roundabout. This allows routing to 
navigate through the roundabout more fluidly.

/

et /
/

  * /Le tag //ref
=*//n'a pas de
sens sur un carrefour. Les références désignent les routes et non
les carrefours, même si une route est coupée par un carrefour
giratoire, il ne faut pas reporter la référence de cette route sur
ce chemin./

La version française date de 2011 pour cette partie./
/

Avant le 9 avril 2019, la page anglaise ne mentionnait pas de ref.

Les modifs correspondantes datent du 9 au 25 avril./
/

En conclusion je donnerais raison à la personne de Montpellier. Et en 
conséquence entrerais un ticket dans Osmose pour éviter ce signalement.


À mon avis on peut virer tout test de ref sur les rond-points car si 
jamais une route principale commence sur un rond-point, le rond-point 
peut avoir pour référence celle de la route.


Jean-Yvon

Le 03/07/2019 à 07:45, marc marc - marc_marc_...@hotmail.com a écrit :

Bonjour,

Le 03.07.19 à 00:13, François Lacombe a écrit :

Je vous relaye cette interrogation, postée à bon escient sur le wiki,
par la métropole de Montpellier
https://wiki.openstreetmap.org/wiki/FR_talk:Tag:junction%3Droundabout

je comprend la règle comment étant : "un carrefour est un élément
ponctuel et on ne met pas la ref de la route sur tous les noeuds
de la route"
par extension, on fait pareil avec un "gros carrefour" style ronds-point.
je saisis pas trop l'argument du guidage gps.
on est perdu si le guidage dit "prenez la 1er sortie du rond-point"
au lieu de "prenez la 1ère sortir du rond-point ref 123 ?"
faudrait par contre aller voir pq c'est pas pareil en fr et anglais.

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


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




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

Re: [OSM-talk-fr] Attribut ref sur les ronds point : la question de Montpellier

2019-07-04 Per discussione Frédéric Rodrigo

Cela a déjà été discuté et je ne pense pas qu'il y a lieu de changer de 
position.


Certains pays on des ref de carrefours, mais pas la France.

Que faire quand plusieurs routes passant par un carrefour ont des ref ?

Frédéric.


Le 03/07/2019 à 11:21, osm.sanspourr...@spamgourmet.com a écrit :


Les versions anglaise et française sont non seulement différentes mais 
explicitement contradictoires :



/Ref Tagging/

// 


/Roundabout with ref tagging consistent with connecting roads/

/For roundabouts that have ways either continuing through, or ending 
at the roundabout, //ref 
=*//and //int_ref 
=*//tags from those 
ways should be added to that roundabout. This allows routing to 
navigate through the roundabout more fluidly.

/

et /
/

  * /Le tag //ref
=*//n'a pas de
sens sur un carrefour. Les références désignent les routes et non
les carrefours, même si une route est coupée par un carrefour
giratoire, il ne faut pas reporter la référence de cette route sur
ce chemin./

La version française date de 2011 pour cette partie./
/

Avant le 9 avril 2019, la page anglaise ne mentionnait pas de ref.

Les modifs correspondantes datent du 9 au 25 avril./
/

En conclusion je donnerais raison à la personne de Montpellier. Et en 
conséquence entrerais un ticket dans Osmose pour éviter ce signalement.


À mon avis on peut virer tout test de ref sur les rond-points car si 
jamais une route principale commence sur un rond-point, le rond-point 
peut avoir pour référence celle de la route.


Jean-Yvon

Le 03/07/2019 à 07:45, marc marc - marc_marc_...@hotmail.com a écrit :

Bonjour,

Le 03.07.19 à 00:13, François Lacombe a écrit :

Je vous relaye cette interrogation, postée à bon escient sur le wiki,
par la métropole de Montpellier
https://wiki.openstreetmap.org/wiki/FR_talk:Tag:junction%3Droundabout

je comprend la règle comment étant : "un carrefour est un élément
ponctuel et on ne met pas la ref de la route sur tous les noeuds
de la route"
par extension, on fait pareil avec un "gros carrefour" style ronds-point.
je saisis pas trop l'argument du guidage gps.
on est perdu si le guidage dit "prenez la 1er sortie du rond-point"
au lieu de "prenez la 1ère sortir du rond-point ref 123 ?"
faudrait par contre aller voir pq c'est pas pareil en fr et anglais.

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


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




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

Re: [Talk-lv] Rescuing tree import in Valmiera made by Pēteris Brūns

2019-07-04 Per discussione Rihards

On 03.07.19 12:37, Peteris Bruns wrote:
> Hi,
> 
> mainly all I can explain was done already answering to Michael at this
> thread https://www.openstreetmap.org/changeset/57269387#map=14/57.5362/25.4167
> 
> In general, I'm now not ready to check all steps required by import
> procedure. Feel free to delete/revert changesets.

Data quality wise, what other problems exist besides the excess hyphen?
I hope we can salvage this one. There have been edits on top of it
(mostly removal of some cut trees), and I'm not aware of massive
technical problems with it so far.

> Data used in import are available
> here http://gisnet.lv/~kartes/OSM/valmiera2018/ for anyone ready to go
> with complete import process and ready to clarify legal aspects.
> WMS service based on data is here http://gisnet.lv/cgi-bin/osm_vektori
> 
> Best regards,
> 
> 
> On Wed, 3 Jul 2019 at 11:38, Mateusz Konieczny  > wrote:
> 
> (sorry for English)
> 
> Is somebody interested in rescuing tree import in Valmiera made by
> Pēteris Brūns?
> 
> See https://www.openstreetmap.org/user/Pēteris Brūns/history
> 
> There are following problems
> 
> - apparently this import was never discussed
> - copyright of data added is unknown
> - data quality was not verified before import and there are
> complaints about data quality
> - misuses tags (leaf_type=evergreen)
> 
> Is somebody interested in
> - verifying and documenting license
> - checking whatever data quality is acceptable
> - checking with community whatever keeping this imported data is
> acceptable
> - verifying with https://lists.openstreetmap.org/listinfo/imports
> whatever what was done is enough to
> keep this imported data
> - document this import as required at
> 
> https://wiki.openstreetmap.org/wiki/Import/Guidelines#Step_4_-_Documentation
> - mentioning what was done in changesets to explain situation to others
> 
> I notified also author, but given that this account was used solely
> for the import I am not
> expecting a reply.> 
> 
> -- 
> pb-- 
 Rihards

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

[Talk-lv] osm tikšanās Rīgā, 2019-07-11

2019-07-04 Per discussione Rihards

Pēc ilga pārtraukuma, aicinām visus uz OSM tikšanos Rīgā
nākamceturtdien, 2019-07-11.

Papildus citām OSM tēmām, šī ir iespēja tikties ar Zverik (Ilja Zverev),
bijušo maps.me izstrādātāju un vispār lielu OSM ekspertu.
Ja ir kāda tēma, par kuru no viņa labprāt dzirdētu nelielu lekciju,
sūtiet idejas.

Tikšanās vieta vēl nav noteikti, bet drīz ziņosim.
-- 
 Rihards

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

Re: [OSM-talk] Reordering and rewriting Good Practice wiki page

2019-07-04 Per discussione Tom Pfeifer


On 04.07.19 05:53, Joseph Eisenberg wrote:

I've reordered and reworded several sections of the Good practice
page: https://wiki.openstreetmap.org/wiki/Good_practice


On 04.07.2019 11:27, Frederik Ramm wrote:

I would prefer if far-reaching edits to essential pages that describe a
community consensus would be made on a user page first so we can
discuss, rather than applying the "be bold" motto here. 


That would also avoid dozens of small editorial edits, going back and forth, 
among the structural ones.


This is not to criticise the edits you made, just a matter of principle.
In fact I find our edits make sense and generally improve the page.


Well, I do criticize that paragraphs, which have been restored after your removal, and a reason was 
given in the comment for restoring, is being removed again in a later edit, following you personal 
opinion. Please don't start edit wars.


tom

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

Re: [Talk-GB] Importing NaPTAN Data

On Tue, Jul 2, 2019 at 11:07 AM Ed Loach  wrote:

> highway=bus_stop
> public_transport=platform
> source=naptan
> naptan:verified=no
> name=(NaPTAN name)
> naptan:AtcoCode=(whatever)
> naptan:NaptanCode=(whatever)
>
> If the bus stop type is not MKD I add
>
> naptan:BusStopType=(bus stop type)
>
> and if the status is not "act" I add
>
> naptan:Status=(status)
>

These tags all seem reasonable to import to me. Would be curious to learn
more about your route maintenance process. I have a list of local bus route
relations I've been meaning to update, but it's hard to do so without all
of the stops mapped (hence my desire to import the available data).

> ___
> 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] Ways divided by paint?

2019-07-04 Per discussione Philip Barnes

On Thursday, 4 July 2019, Snusmumriken wrote:
> On Thu, 2019-07-04 at 13:50 +0200, Mateusz Konieczny wrote:
> > I strongly disagree with this idea,
> > and multiple times changed such splits
> > back to one way.
> 
> I would consider that as an act of vandalism by removing ground truth
> information that your fellow mappers have gathered and encoded in the
> database.
>
It is only vandalism if you loose information, if you are improving the mapping 
by changing such misleading information to correctly mapped turn lanes then it 
is improving the map.

Phil (trigpoint)



 
> > 
> > 
> > Jul 4, 2019, 11:49 AM by snusmumriken.map...@runbox.com:
> > > On Wed, 2019-07-03 at 14:03 -0600, Jack Armstrong Dancer--- via
> > > talk
> > > wrote:
> > > > I've always had the impression we should not create separate
> > > > traffic
> > > > lanes unless "traffic flows are physically separated by a barrier
> > > > (e.g., grass, concrete, steel), which prevents movements between
> > > > said
> > > > flows."
> > > 
> > > A painted line that has the legal status of "do not cross" is a
> > > perfectly fine reason to have a separate way.
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

-- 
Sent from my Sailfish device
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Traduire le wiki ?

Le 04.07.19 à 15:27, Vincent Bergeot a écrit :
> https://wiki.openstreetmap.org/wiki/FR:Key:shop#Autres
> shop=pest_control
> j'ai voulu traduire la description dans le tableau

si cela n'a pas changé récement, le tableau reprend
les intitulés des pages de chaque tag via taginfo.
donc la traduction se fait sur
https://wiki.openstreetmap.org/wiki/FR:Tag:shop%3Dpest_control

Ensuite la nuit taginfo met à jour sa base et cela devrait
être à jour dans le tableau du wiki au petit matin.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] booking=* <> reservation=*

Bonjour,

je fais écho ici d'une discussion qui a commencé sur la ml tagging
pour indiquer qu'un POI accepte/refuse/recommande une réservation,
la clef la plus courante est reservation=*
un contributeur avait crée une page booking=* et l'avait
ajout en recommandation sur plusieurs autres pages.
mais outre le fait d'avoir 2 clefs pour la même chose,
cela entrait en conflit avec booking=l'url booking.com
En est arrivé la conclusion de migrer
- booking=* vers reservation=* lorsque concerne la possibilité ou non de 
réserver
- garder dans booking=* les url booking
- il y a aussi quelques urls de réservation non booking.
rien n'a été décidé mais sans doute que reservation:website serrait le + 
cohérent.

a noter que le plus grand nombre de cas (125) sont des lignes de
train passant par la France. à vos correcteurs, prêt ? partez :D
et si cela ne motive personne, je m'y collerai :)

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

[OSM-talk-fr] Traduire le wiki ?

2019-07-04 Per discussione Vincent Bergeot


Bonjour,

je cherche à ajouter un magasin qui lutte contre les termites ! soit 
https://wiki.openstreetmap.org/wiki/FR:Key:shop#Autres


shop=pest_control

j'ai voulu traduire la description dans le tableau et en fait je ne sais 
pas faire.


Quand je modifie, je tombe que sur la version anglaise, je sens bien 
qu'il y a une histoire intéressante derrière tout cela (à savoir 
économiser du temps à traduire) mais je n'ai pas trouvé où et comment 
faire simplement (si cela peut-être simple !).


Une piste ?

Bonne journée

--
Vincent Bergeot


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

Re: [OSM-talk] Ways divided by paint?

2019-07-04 Per discussione Snusmumriken

On Thu, 2019-07-04 at 13:50 +0200, Mateusz Konieczny wrote:
> I strongly disagree with this idea,
> and multiple times changed such splits
> back to one way.

I would consider that as an act of vandalism by removing ground truth
information that your fellow mappers have gathered and encoded in the
database.

> 
> 
> Jul 4, 2019, 11:49 AM by snusmumriken.map...@runbox.com:
> > On Wed, 2019-07-03 at 14:03 -0600, Jack Armstrong Dancer--- via
> > talk
> > wrote:
> > > I've always had the impression we should not create separate
> > > traffic
> > > lanes unless "traffic flows are physically separated by a barrier
> > > (e.g., grass, concrete, steel), which prevents movements between
> > > said
> > > flows."
> > 
> > A painted line that has the legal status of "do not cross" is a
> > perfectly fine reason to have a separate way.



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

Re: [OSM-talk-fr] Données routières ouvertes en France

2019-07-04 Per discussione ades

Dans  mon secteur, sur le cadastre édition Etalab, ou édition Edigeo, les 
tronçons de voie figurent, avec leur nom (en général).
Mais… il manque un certain nombre de voies mineures
Mais …ce sont des tronçons qui ne sont souvent pas raccordés les un aux autres, 
même si au niveau géométrique c’est plutôt pas mal.
Mais…que ce soit Etalab ou Edigeo c’est quelques fois un peu difficile de gérer 
les couches téléchargées…

Donc, de toute façon pas gagné avec le cadastre.

> Le 4 juil. 2019 à 12:50, Maël REBOUX  a écrit :
> 
> Bonjour,
> 
> Il n'y a pas de route / de géométrie de tronçon routier dans le cadastre. Il 
> y a juste une table des voies avec des dénominations parfois pas utilisable.
> Si c'est mis en source pour le nom de voies dans OSM : c'est bien sûr comme 
> source du nom, pas de la géométrie.
> 
> Pour des questions de licence, vous ne pouvez pas à ce jour (enfin je pense) 
> utiliser les données IGN que vous avez identifié.
> Sur le GéoPortail : oui c'est forcément source BD Topo. Question de cohérence.
> A part le fond de plan cadastre et OSM bien sûr...
> 
> En données vraiment libre de couverture nationale il n'y a donc que OSM sur 
> le marché.
> Il y a cependant des collectivités locales qui mettent leur données 
> référentielles de voies en open data. Voir sur data.gouv.fr
> 
> https://www.data.gouv.fr/fr/search/?q=filaire+de+voies 
> 
> https://www.data.gouv.fr/fr/search/?q=tron%C3%A7ons+voies 
>  
> 
> 
> cdt,
> 
> 
> De: "Julien Minet" 
> À: "Discussions sur OSM en français" , "Jérôme 
> Amagat" 
> Envoyé: Jeudi 4 Juillet 2019 12:06:19
> Objet: *** BULK *** Re: [OSM-talk-fr]  Données routières ouvertes en France
> 
> Merci pour les réponses de marc_marc et Jérôme. 
> D'après ce que je comprends, la source= cadastre est effectivement la source 
> des noms, et cette info a probablement été ajoutée sur base d'édition 
> manuelle avec la couche WMS du cadastre. Visiblement, il n'y a pas eu 
> d'import dans OSM de routes du cadastre puisque cette donnée (la géométrie) 
> n'existe pas au cadastre.
> 
> En fait, j'aimerai connaitre la source originelle des rues qui sont affichées 
> sur geoportail.fr. Je suspecte que ce soit la BD Topo 
>  de l'IGN, qui n'est malheureusement pas 
> libre. 
> Il semble qu'on va devoir utiliser OSM pour ce projet (ben tant mieux). A 
> voir si la complétude des rues sur OSM est satisfaisante en France, une idée 
> sur ce point ? (vaste question, je serai incapable de répondre pour la 
> Belgique!)
> Bonne journée, 
> Julien
> 
> 
> On 04/07/2019 03:10, Jérôme Amagat wrote:
> Les tag source=cadastre c'est le plus souvent pour le name=* de la route voir 
> la ref.
> Le cadastre est bien vectoriel sur une bonne parti de la France mais on y 
> trouve le bâti et les parcelles de terrain mais pas les routes à ma 
> connaissance.
> on peut quand même en déduire où sont une partie des routes : c'est là où il 
> n'y a pas de parcelle :) mais une petite partie des routes sont sont sur des 
> parcelles...
> 
> on peut le trouvé là : 
> https://cadastre.data.gouv.fr/datasets 
> 
> 
> 
> Le mer. 3 juil. 2019 à 17:33, Julien Minet  > a écrit :
> Bonjour, 
> Je travaille à Champs-Libres.coop en Belgique où nous développons des 
> applications avec les données OSM. 
> Pour un de nos projets, on cherche des données de réseaux routiers en 
> Belgique et en France. Par données de réseau routier, j'entends:
> 
> tout type de route carrossables, de la "residential/unclassified" à la 
> "motorway"
> la géométrie des routes
> des attributs comme le nom, et si possible le "ref", "lanes", "width", voire 
> d'autres infos. 
> Bien sûr OSM est une bonne option que nous espérons proposer au client, mais 
> j'aimerai prospecter les sources officielles de données existantes en France 
> (et éventuellement comparer les 2). Après quelques recherches, je vois que 
> les données de l'IGN (BD Carto et BD Topo) ne sont pas libres mais 
> disponibles après paiement. Il y a bien Route 500 
>  dispo gratuitement mais 
> cela ne concerne que les "grandes" routes.
> Or il se trouve que sur certaines routes en France dans OSM, j'ai trouvé 
> plusieurs fois cette source : "cadastre-dgi-fr source : Direction Générale 
> des Impôts - Cadastre. Mise à jour : 20XX". 
> Je me suis donc renseigné sur l'import du cadastre en lisant les pages du 
> wiki  
> mais je n'ai pas trouvé qu'elle était la source originelle qui a servi à cet 
> import. D'où ma question: est-ce que les données cadastrales des voiries en 
> France sont disponibles en vectoriel? Ou bien est-ce que ces données ont été 
> digitalisées à partir d'un WMS? 
> Plus largement, connaissez-vous des

Re: [Talk-it] Flame su old_name

2019-07-04 Per discussione Martin Koppenhoefer



sent from a phone

> On 4. Jul 2019, at 12:49, solitone  wrote:
> 
> Non è né un altro nome “ufficiale",


alt_official_name

qualcuno c’è  ;-)
https://taginfo.openstreetmap.org/keys/alt_official_name



> né un nome locale


loc_name



alt_name è semplicemente un nome alternativo. Non ha implicazioni di 
ufficialità o uso locale.

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

Re: [OSM-talk] Ways divided by paint?

2019-07-04 Per discussione Martin Koppenhoefer

sent from a phone

> On 4. Jul 2019, at 11:49, Snusmumriken  wrote:
> 
> A painted line that has the legal status of "do not cross" is a
> perfectly fine reason to have a separate way.

it doesn’t apply to many people though, for example pedestrians or emergency 
vehicles.
The definition for a separate highway way is that it implies a separate 
carriageway. We’ve set it like this. IMHO it can hardly put into discussion at 
this point. If you want to map by a different definition, safest would be to 
use a different key.

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

Re: [Talk-it] Source dubbio

2019-07-04 Per discussione Martin Koppenhoefer



sent from a phone

> On 4. Jul 2019, at 13:37, Andy Townsend  wrote:
> 
> Thanks for everyone's patience - I believe that I've now reverted the problem 
> changesets.


Thank you very much for your help!

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

Re: [Talk-it] Nome linea elettrica che cambia

2019-07-04 Per discussione Graizzaro Gianfranco

La linea in questione è composta da 7 fili 3 nord è una linea, 3 sud è
un'altra linea, 1 in alto, si chiama cavo di guardia e serve per i fulmini.

Gianfranco



--
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] Ways divided by paint?