Re: [Talk-de] Änderungen im Wiki: Tag:public transport=platform

[Jo]

Die Linien gehen in route_ref, getrennt mit ;

Steignummern oder Buchstaben gehen in local_ref.

ref ist für Identifikationsnummern. Jede Haltestelle hat eine andere eigene
ref-nummer.

Ich würde name nur auf das pt=platform/highway=bus_stop setzen, weil ich
die nur einmal haben woll, aber das ist in Deutschland anders gemacht.

Ich würde in name "Gemeinde Haltestellename Bahnsteig" kombinieren. Finde
ich am deutlichsten. Aber in die meiste Orte im Welt ist Gemeinde nicht
dabei.

Polyglot

On Thu, Aug 8, 2019 at 1:32 PM Roland Olbricht 
wrote:

> Hallo Nzara,
>
> da pflichte ich Martin dringend bei. Gut 99% aller Name-Nutzungen an
> public_transport=platform in Deutschland sind die Namen der Station.
>
> Ich habe das für die fünf größten Bundesländer ausgezählt:
>
> Land Hst mit Name  Hstname  Steigref
> NRW673246630466299 5
> Bayern 391263409733991   106
> BaWü   256732215922002   157
> NDS22372204432038063
> Hessen 22967214852147124
>
> Da es eine händische Sichtung der Hstnamen ist, werde ich das auch nicht
> aufs ganze Bundesgebiet ausdehnen; der Trend ist eindeutig.
>
> Wer selber bei sich auszählen möchte, kann alle vorkommenden Namen listen:
> https://overpass-turbo.eu/s/Lp4
> Bitte die Bounding-Box zum Zielort schieben.
>
> Wenn es einen Sonderwunsch gibt, kann man den gerne diskutieren. Aber er
> gehört auf keinen Fall in die Tag-Dokumentation; Leser der Dokumentation
> könnten das für anerkannt halten. Wenn ein Tag wie hier breite
> Verwendung gefunden hat, sollte es auch auf keinen Fall umdefiniert werden.
>
> Ich persönlich halte diesen Sonderwunsch auch nicht für sinnvoll. Ziel
> muss es sein, das Arbeiten für den Mapper einfach zu halten, und da ist
> es besser, wenn wir für jedes Objekt (Straße, Ladengeschäft,
> Bushaltestelle, etc.) beibehalten: Name ist die Bezeichnung, die am
> Schild drüber dafür steht.
>
> Viele Grüße,
>
> Roland
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-us] data freshness boogie man (was: request for review of plan for scripted edit)

[Jmapb]

On 8/8/2019 5:52 PM, Bryce Jasmer wrote:


I’m really opposed to this idea of scaring people away from editing
objects with the “data freshness” boogie man argument. If someone
really cares about freshness, the entire history of an object is
available to you.


That's true for any single object. But what if you want to query for
stale data in a given area, in preparation for a survey? Accessing each
object's history makes the process exponentially more complicated. If
you can mange to do that, then you could try to skip edits by known bot
accounts... but there are always more. You can try to filter out
changesets with bot=yes, which well-behaved bots will set. But lots of
people make these wide-ranging edits semi-manually using JOSM or Level0.

I understand that this particular objection to armchair data cleanup is
far from universal. But the compulsive reformatting of incorrect data
makes me roll my eyes a bit. I find it useless bordering on ridiculous
when I see a mapped restaurant that's been gone for years, but someone's
added branding tags, someone's prefixed the website with http://,
someone's reformatted the phone number, someone's fixed the opening
hours, someone's corrected the cuisine... but nobody has bothered to see
if the place actually still exists.

I think my prejudice stems from reading this cautionary tale on the wiki
in my OSM infancy:
https://wiki.openstreetmap.org/wiki/What%27s_the_problem_with_mechanical_edits%3F
(I see now that this was originally written by Frederik Ramm, though I
had no idea who that was at the time.)

The bottom line, though, is that a well-planned, well-discussed, and
well-behaved bot is by far the *best* way to make these sorts of edits,
if someone feels they must be made. My preference would be to only touch
recently edited objects but that's by no means a dealbreaker.

Jason


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

Re: [Talk-ee] SviMik_import is back to life

[SviMik via Talk-ee]

Hi Mihkel Oviir (upd: and Mihkel Rämmel too!),

I'm glad to see more people here, even if some of them sound like they had a 
really bad morning. I had already jumped to conclusion that Jaak is the last 
person in talk-ee, which makes the community essentially dead since there is no 
one I can discuss anything with. I checked the mailing list history a week ago, 
and found that this year is completely empty (only Jessica's messages in 
February about HOT Microgrants, but she's not from the local community).

To Mihkel Oviir:

1) I'm using my OSM name and I find it adequate. I wish others would do the 
same, so I could make a connection between the person who speaks to me and his 
OSM profile. But I need to point out that "I wish" doesn't mean "I'm asking you 
to do that" unlike you just have done. It's completely normal to choose a 
nickname in the Internet, we're not some government organization to be that 
formal. Again, you're just provoking further conflicts with such an attitude, 
let's cease that.

2) I want to apologize to Jaak, I went too far with my accusation. Let's just 
not exclude people who live in Estonia from the local community just because 
they speak a different language.

3) You have a point. It's another import. But I just wish to point out that I 
do maintain my previous imports too. For example, I do update addresses on the 
buildings I imported in 2013. Of course, only if no one else touched that 
building or any tags on it after that.

3) Honestly, me neither. I just mocked Jaak a bit (sorry, Jaak!)

4) I think buildings and addresses are tightly connected. Sure you can import 
the address nodes without importing the buildings, but even I would be against 
that kind of import (at least, if there is a way to avoid doing that). A 
landuse import is even more questionable thing to do (and closer to "if you 
need Maa-amet — you have Maa-amet").

5) All my tools had JOSM buttons from the very beginning. I'm sorry I didn't 
include ID though, I'll see if I can do that. As a workaround you can use a 
link to open that place in OSM map and click the Edit button from there.

6) I didn't quite get what nickname you are talking about. If SviMik_import - 
that's a separate account made just for imports. It's a good practice in OSM to 
do the imports using a dedicated account so it would be easier to control, 
verify and monitor it, as well as to fix things if something goes wrong.

7) It was the easiest way to do it. Also, I was thinking that all places 
equally deserve the attention, so I didn't see any problem with that. Also, I 
think if I give a choice, most people would just select Tallinn, but it's the 
last place that needs any imports. It was more intended for rural areas, and 
people are unlikely to have any preferences between villages they don't know 
anyway, so that would be a useless option. The idea of sorting the tasks looks 
great at the first glance, but it will increase the risk that if two people 
bump into each other, they may get stuck mapping the same things for the entire 
session. I'll have to invent some algorithm to prevent it, and I think it's an 
overcomplication for a system with such a simple task.

Oh horseapples, Mihkel Rämmel got into my spam folder for some reason. Now he 
probably thinks I'm ignoring people. Let's fix that.

>non-square buildings
Since non-square buildings are like <1% of all the buildings I decided not to 
import them (if someone clicked OK in the validator, I'm really sorry for that. 
There's a clear instruction to decline the import if the outlines do not match).

>Currently buildings do not use same nodes despite sharing a wall.
Yes, I'm aware of that. Almost impossible to do anything with that, especially 
if another outline was created by a human. Not to mention there's a chance that 
that person not gonna be happy with that. Imagine if that would be a Jaak's 
building :D

>A tool to assist going through such cases afterwards would not hurt.
If by tool you mean a list with errors that just says "open these places in 
your editor and fix them" then it's quite possible to do. Though I already have 
a bunch of them, an nobody gives a buck.

For example, missing roads:
http://osm.svimik.com/noroad.php
- this page shows all places where a building was imported, but a road still 
needs to be mapped by a human.

Missing streets:
http://osm.svimik.com/nostreet.php
- that's a bit more challenging. You need to open Maa-amet and figure out why 
there's no match between building addresses and the street names. Either a 
street must be (re)named, or the buildings need to be fixed.

To Jaak:
>without context
I'm having hard time to imagine what kind of context do you need. When I map 
something in JOSM - I just trace everything that catch my attention, the 
knowledge of what city it is wouldn't change how I do it. Maybe I'm just a bad 
mapper and there's something I haven't learned?

>so there is no way to validate what is real street name
The 

Re: [OSM-ja] JA: Available Dataの改定提案の議論について

[Satoshi IIDA]

いいだです。

まとめの方向性に賛成します。
1行でまとめるよりも、行を2つにわけてしまうのはどうでしょう。

> ■現状
> ・判定：◎
> ・用例：ウェブサイト上の店名、住所、電話番号など
> ・判定の理由：事実情報
個人的には、「一次情報」というよりも「オフィシャルな情報（公式情報）」の表現のほうがしっくりくるな、と思っています。
なので、「オフィシャルであるウェブサイト上の。。。」あたりでどうでしょう。

> ■現状
> ・判定：☓
> ・用例：オフィシャルな情報以外のウェブサイト上の店名、住所、電話番号など（例: Wikipedia, Wikidata,
著作権保護された地図データ、飲食店ランキングサイト等）
> ・判定の理由：事実情報ではあるが、データベース権に抵触する可能性があるため

こんなかんじです。

> 「Wikipedia に掲載されているからこの情報は削除せよ」などと言い出す人が出てくると思います (本来は「Wikipedia
しか出典がない情報は削除せよ」であるべきです)。
はい、これは可能性としてとてもあると思っています。
別の語を使う、となると、例えば「対象データの例」とかでしょうか？

地番と地籍と住所に関しては、個人的には大好物の話題ではあるのですが、
ちょっと本題から離れちゃいそうなのでどこかで機会ほしいです :)
（一次情報、ではなく他の言い回しのほうがよいのでは、という意見には上記の通り賛成です）



2019年8月8日(木) 16:07 ISHIKAWA Takayuki (Talk-ja 経由) :

>
> こんにちは、奈良の石川です。議論の整理、ありがとうございます。
>
> On Sunday, August 4, 2019, 7:19:39 AM GMT+9, 石野貴之 
> wrote:
> >これを踏まえると、当初の村本さんの提案
> >https://lists.openstreetmap.org/pipermail/talk-ja/2019-June/010597.html
> >のうち、
> >> ■現状
> >> ・判定：◎
> >> ・用例：ウェブサイト上の店名、住所、電話番号など
> >> ・判定の理由：事実情報
> >については現状を維持し(ただし、公式サイト上の一次情報に限ることを明記する)、WikipediaやWikidataについてはデータベース権にも
> >触れた上で判定:×とするのが妥当なところだと考えられますが、皆様のご意見はいかがでしょうか。
>
>
> 基本的にそれでよいのではないかと思います。ただ、以下の2点が気になります。
>
> (1)
> 「公式サイト上」の情報に限ることは良いと思いますが、「一次情報」に限る必要性を私は感じません。以前も書きましたが、例えば地番表記に於いては法務局に存在する情報こそが一次情報であり、当該地物の所有者・管理者がいくら公式に地番表記の住所を発表してもそれは二次以降の情報に過ぎない、というのが私の立場です。公式に発信されている情報であれば、何次情報であろうと当該地物の所有者・管理者が責任をもって発信しているでしょうから、「一次情報」に限る必要はないと考えます。(私の解釈が絶対に正しいという主張ではなく、そういう解釈をする人も正しく線引きできる表現が望ましい、という主張です。)
>
> (2) 今回の議論に直接含まれてはいないのですが、そもそも「用例」という語がまずいと思います。英語版では「data」となっており、data
> という語には資料や出典という意味合いが含まれますが、日本語の「用例」という語には資料や出典と言う意味合いが含まれません。そのため、「用例」表記のままですと、「Wikipedia
> に掲載されているからこの情報は削除せよ」などと言い出す人が出てくると思います (本来は「Wikipedia
> しか出典がない情報は削除せよ」であるべきです)。以前、これと同様の事例が、個人住宅の表札に関して主張されたこともあります。「JA:Available
> Data」の文章は、複数の解釈の余地がないように正しく記述されることが望ましいと思います。
>
> --
> 石川
> ___
> 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

Re: [talk-au] [FOSS4G-Oceania] Considering future Open Geospatial conferences in Oceania

[adam steer]

hey community

I want to temper this a little with Bruce Bannerman’s recent and very
relevant comments on where OSGeo Oceania and FOSS4G SotM Oceania are at.
The main question being:

‘how many things can we do at once?’

In my mind, a laser focus on bedding in OSGeo Oceania and sorting out all
the wrinkles with respect to OSGeo and OSM chapterhood / board processes /
who the org represents / how to represent people who don’t feel immediately
bonded to the idea is the first community priority.

Yes, since 2017 we’ve had remarkable success and we should aim to keep that
momentum. To use an analogy, I feel this revitalised fast-growing tree of
OSGeo Oceania needs a broader base and deeper roots right now.

We need to establish and broaden our regional connections and volunteer
base.

With that in mind, it’s definitely time to start thinking about a 2020
regional event. I’m sure the OSGeo Oceania board will be looking for
proposals soon!

Those are my thoughts - I hope they’re taken as virtual organic mulch and
well composted manure for the future of OSGeo Oceania, and not cold water….

Regards,

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

Re: [Talk-us] Request for review of plan for scripted edit

[Mike N]

On 8/8/2019 5:25 PM, Paul Norman via Talk-us wrote:
Given the low numbers of 7-digit numbers I recommend correcting them 
manually rather than writing code to do it.


  On this one I'm not sure how introducing an error-prone keyboarding 
exercise into the mix is an improvement over a programmatic solution. 
At least with the programmatic solution, a typo applies to all and is 
more easily spotted.


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

[OSM-talk] International Day of the World's Indigenous Peoples

[Suchith Anand via talk]

 
  
The International Day of the World’s Indigenous Peoples is 9 August. This day 
recognizes the achievements and contributions of the world's 370 million 
indigenous people who live in more than 90 countries. 





I wish to join the world in honouring and acknowledging the resilience, dignity 
and strength of indigenous peoples around the world. GEO community are marking 
this day by announcing the launch of the GEO Week 2019 Hackathon, an innovative 
hackathon to advance the use of Earth observation (EO) data by and for youth in 
indigenous communities. The hackathon is being managed by Diana Mastracci with 
support from the GEO community. The hackathon will address EO-based challenges 
and will be co-designed by indigenous youth throughout the world. The goal is 
to encourage the co-development of innovative EO-based applications that are 
locally relevant and enhance the communities way of learning. It will promote 
the use of open EO data among indigenous communities and ultimately to 
co-design locally relevant free and open source software. This will result in 
new means for aligning local/ traditional knowledge and science co-production 
across cultural and generational lines.[1],[2].




Details athttp://www.earthobservations.org/geoweek19.php?t=hackathon





Join us for the GEO Week 2019 and the GEO Ministerial Summit in Canberra, 
Australia (4-9th Nov 2019). Canberra means ‘meeting place’ in Ngunnawal, the 
local indigenous language. Recognizing the history of the land and its 
traditional custodians, GEO Week will bring together diverse people and 
cultures to support and sustain our planet and communities.




Best wishes,




Suchith







[1]https://www.earthobservations.org/geo_blog_obs.php?id=371


[2]https://www.earthobservations.org/geo_blog_obs.php?id=370












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

[Talk-GB] (no subject)

[Rob Nickerson]

Hi all,

The following from Dorothea at OSMF. We'll see what scope there is for OSM
UK to answer (likely just re-iterating our aims and membership size). I
encourage individuals to respond too.

Best wishes
Rob

Hello,

The following survey on global and local communities in OpenStreetMap
was developed by board members. The survey is not quantitative and its
aim is to stimulate  discussions in local communities and at the Local
Chapters Congress at SotM.
https://osmf.limequery.org/428835

~ The survey will run for two weeks.
~ Only one question is mandatory: "How can we share your answers?".

There is more information on the scope of the survey and approach on the
opening page.

warm greetings,

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

Re: [Talk-us] Request for review of plan for scripted edit

[Bryce Jasmer]

I’m really opposed to this idea of scaring people away from editing objects
with the “data freshness” boogie man argument. If someone really cares
about freshness, the entire history of an object is available to you.

On Thu, Aug 8, 2019 at 12:57 PM Kevin Broderick 
wrote:

> I'm of mixed feelings on the apparent freshness, but as long as the
> guidelines are followed so changesets are of reasonable size and easily
> identified as scripted, I don't see much of an issue.
>
> While having an automated script make assumptions caused me to twitch a
> little, the reality is that a human is going to make the same assumption.
> If I see a seven-digit number on a sign and want to dial it, I'm going to
> assume that the area code is 207; if I'm across the state line in New
> Hampshire, I'm going to assume 603. If that assumption isn't correct, the
> source data is bad anyhow, and adding the implicit area code isn't making
> it substantially worse. Have you been able to discern how many seven-digit
> numbers are in the system?
>
> On Thu, Aug 8, 2019 at 2:56 PM Jmapb  wrote:
>
>> On 8/8/2019 1:28 PM, Alex Hennings wrote:
>> > Community,
>> >
>> > I'm planning a scripted change and would like feedback. Plans are
>> > outlined here:
>> > https://wiki.openstreetmap.org/wiki/Automated_edits/blackboxlogic
>> >
>> > I'd appreciate feedback or questions in the 'Discussion' portion of
>> > that wiki page, or within this email list.
>>
>> Hi Alex!
>>
>> First, a possible typo: I think "Nodes, Ways and References" should be
>> "Nodes, Ways and Relations"?
>>
>> I'm a fan of the +1-xxx-xxx- format, since it's the only standard
>> format that's visually intuitive to North American users. I often switch
>> numbers to this format when I make updates to an existing POI.
>>
>> Personally, though, I've always felt a little uneasy about automated
>> updates like this because they give a false impression of the freshness
>> of the data. If it's been five years since any "real" updates to a POI,
>> I'd rather that the date of last update reflected that. It's hard to
>> gauge the community consensus on this issue, but IMO running this on
>> POIs that have been manually updated (ie not by a mass edit) in the last
>> 6 months would be fine.
>>
>> Regarding the single area code question... now that cell phones, VOIP,
>> and nationwide calling plans are ubiquitous, the idea that a certain
>> area code refers to a certain area is steadily eroding. I have started
>> to see a few businesses with out-of-state phone numbers on their
>> signs... but at this point it's still more likely that an out-of-state
>> area code is an error or SEO spam. I'd suggest that these would go into
>> your "Manually review or flag" category.
>>
>> Regardless, the idea that an area can have a single "traditional" area
>> code is still true. Personally I have no problem with prepending the
>> traditional area code onto 7-digit phone numbers. (I do it all the time
>> in manual mapping.)
>>
>> Finally, thanks for posting your tools... I see these are written in
>> CSharp, which I'm only tangentially familiar with. What sort of
>> environment would one need to build these?
>>
>> Thanks, Jason
>>
>>
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
>
> --
> Kevin Broderick
> k...@kevinbroderick.com
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-GB] Solar project: Press interview

[Rob Nickerson]

Hi all,

I've been a bit slow to the solar mapping project but have now picked up
the baton for outreach. If we can get some press lined up do we have any
volunteers to speak with them?

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

[Talk-GB] Rowmaps importing in South Gloucestershire

[Neil Matthews]

In light of some recent edits in South Gloucestershire -- is it ok to
import unsurveyed footpaths based simply on rowmaps data?

Thanks,
Neil

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

Re: [talk-au] [FOSS4G-Oceania] GHG mitigation and FOSS4G SotM Oceania

[Graeme Fitzpatrick]

I've also seen reference to investing in mangroves.

Can't see the particular reference just now, but this also discusses the
concept further

http://awsassets.panda.org/downloads/wwf_iucn_mangroves_investment_effectiveness_guide.pdf


Possibly another option?

Thanks

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

Re: [Talk-us] Request for review of plan for scripted edit

[Paul Norman via Talk-us]

Given the low numbers of 7-digit numbers I recommend correcting them manually rather than writing code to do it.On Aug 8, 2019 2:02 PM, Alex Hennings  wrote:Fixed: references -> relations.Noted: "False impression of data freshness". I hadn't considered this and I would like more opinions.Regarding
 "single area-code Question" I think you're talking about 7 digit 
numbers, and my plan to optimistically appending an area code in cases 
like Maine where there is only one area code. I acknowledge that as the 
weakest of the assumptions but I thought of it as a safe guess and a net
 positive change. For context on why I feel confident, living in Maine 
where we only have one area code, locals will omit the area code 
because we don't need it when dialing locally.Regarding "how many seven-digit numbers" Good question! There are 6 in Maine, 163 in USA.(node    ['phone'~'^([^0-9]*[0-9]){7}[^0-9]*$']    (area:3600063512); // or 3609331155 for usa way    ['phone'~'^([^0-9]*[0-9]){7}[^0-9]*$']    (area:3600063512); relation    ['phone'~'^([^0-9]*[0-9]){7}[^0-9]*$']    (area:3600063512);); out count;The C# tools I'm building should work with any c# IDE. I use VisualStudio which is free, and available on iOS and Windows. I'm happy to help if you want to get them up and running.-Alex

On Thu, Aug 8, 2019 at 3:58 PM Kevin Broderick  wrote:I'm of mixed feelings on the apparent freshness, but as long as the guidelines are followed so changesets are of reasonable size and easily identified as scripted, I don't see much of an issue.While having an automated script make assumptions caused me to twitch a little, the reality is that a human is going to make the same assumption. If I see a seven-digit number on a sign and want to dial it, I'm going to assume that the area code is 207; if I'm across the state line in New Hampshire, I'm going to assume 603. If that assumption isn't correct, the source data is bad anyhow, and adding the implicit area code isn't making it substantially worse. Have you been able to discern how many seven-digit numbers are in the system?On Thu, Aug 8, 2019 at 2:56 PM Jmapb  wrote:On 8/8/2019 1:28 PM, Alex Hennings wrote:
> Community,
>
> I'm planning a scripted change and would like feedback. Plans are
> outlined here:
> https://wiki.openstreetmap.org/wiki/Automated_edits/blackboxlogic
>
> I'd appreciate feedback or questions in the 'Discussion' portion of
> that wiki page, or within this email list.

Hi Alex!

First, a possible typo: I think "Nodes, Ways and References" should be
"Nodes, Ways and Relations"?

I'm a fan of the +1-xxx-xxx- format, since it's the only standard
format that's visually intuitive to North American users. I often switch
numbers to this format when I make updates to an existing POI.

Personally, though, I've always felt a little uneasy about automated
updates like this because they give a false impression of the freshness
of the data. If it's been five years since any "real" updates to a POI,
I'd rather that the date of last update reflected that. It's hard to
gauge the community consensus on this issue, but IMO running this on
POIs that have been manually updated (ie not by a mass edit) in the last
6 months would be fine.

Regarding the single area code question... now that cell phones, VOIP,
and nationwide calling plans are ubiquitous, the idea that a certain
area code refers to a certain area is steadily eroding. I have started
to see a few businesses with out-of-state phone numbers on their
signs... but at this point it's still more likely that an out-of-state
area code is an error or SEO spam. I'd suggest that these would go into
your "Manually review or flag" category.

Regardless, the idea that an area can have a single "traditional" area
code is still true. Personally I have no problem with prepending the
traditional area code onto 7-digit phone numbers. (I do it all the time
in manual mapping.)

Finally, thanks for posting your tools... I see these are written in
CSharp, which I'm only tangentially familiar with. What sort of
environment would one need to build these?

Thanks, Jason



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

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

Re: [Talk-us] Request for review of plan for scripted edit

[Alex Hennings]

Fixed: references -> relations.

Noted: "False impression of data freshness". I hadn't considered this and I
would like more opinions.

Regarding "single area-code Question" I think you're talking about 7 digit
numbers, and my plan to optimistically appending an area code in cases like
Maine where there is only one area code. I acknowledge that as the weakest
of the assumptions but I thought of it as a safe guess and a net positive
change. For context on why I feel confident, living in Maine where we only
have one area code, locals will omit the area code because we don't need it
when dialing locally.

Regarding "how many seven-digit numbers" Good question! There are *6 in
Maine*, *163 in USA*.
(node
['phone'~'^([^0-9]*[0-9]){7}[^0-9]*$']
(area:3600063512); // or 3609331155 for usa
 way
['phone'~'^([^0-9]*[0-9]){7}[^0-9]*$']
(area:3600063512);
 relation
['phone'~'^([^0-9]*[0-9]){7}[^0-9]*$']
(area:3600063512););
 out count;

The C# tools I'm building should work with any c# IDE. I use VisualStudio
 which is free, and available on
iOS and Windows. I'm happy to help if you want to get them up and running.

-Alex

On Thu, Aug 8, 2019 at 3:58 PM Kevin Broderick 
wrote:

> I'm of mixed feelings on the apparent freshness, but as long as the
> guidelines are followed so changesets are of reasonable size and easily
> identified as scripted, I don't see much of an issue.
>
> While having an automated script make assumptions caused me to twitch a
> little, the reality is that a human is going to make the same assumption.
> If I see a seven-digit number on a sign and want to dial it, I'm going to
> assume that the area code is 207; if I'm across the state line in New
> Hampshire, I'm going to assume 603. If that assumption isn't correct, the
> source data is bad anyhow, and adding the implicit area code isn't making
> it substantially worse. Have you been able to discern how many seven-digit
> numbers are in the system?
>
> On Thu, Aug 8, 2019 at 2:56 PM Jmapb  wrote:
>
>> On 8/8/2019 1:28 PM, Alex Hennings wrote:
>> > Community,
>> >
>> > I'm planning a scripted change and would like feedback. Plans are
>> > outlined here:
>> > https://wiki.openstreetmap.org/wiki/Automated_edits/blackboxlogic
>> >
>> > I'd appreciate feedback or questions in the 'Discussion' portion of
>> > that wiki page, or within this email list.
>>
>> Hi Alex!
>>
>> First, a possible typo: I think "Nodes, Ways and References" should be
>> "Nodes, Ways and Relations"?
>>
>> I'm a fan of the +1-xxx-xxx- format, since it's the only standard
>> format that's visually intuitive to North American users. I often switch
>> numbers to this format when I make updates to an existing POI.
>>
>> Personally, though, I've always felt a little uneasy about automated
>> updates like this because they give a false impression of the freshness
>> of the data. If it's been five years since any "real" updates to a POI,
>> I'd rather that the date of last update reflected that. It's hard to
>> gauge the community consensus on this issue, but IMO running this on
>> POIs that have been manually updated (ie not by a mass edit) in the last
>> 6 months would be fine.
>>
>> Regarding the single area code question... now that cell phones, VOIP,
>> and nationwide calling plans are ubiquitous, the idea that a certain
>> area code refers to a certain area is steadily eroding. I have started
>> to see a few businesses with out-of-state phone numbers on their
>> signs... but at this point it's still more likely that an out-of-state
>> area code is an error or SEO spam. I'd suggest that these would go into
>> your "Manually review or flag" category.
>>
>> Regardless, the idea that an area can have a single "traditional" area
>> code is still true. Personally I have no problem with prepending the
>> traditional area code onto 7-digit phone numbers. (I do it all the time
>> in manual mapping.)
>>
>> Finally, thanks for posting your tools... I see these are written in
>> CSharp, which I'm only tangentially familiar with. What sort of
>> environment would one need to build these?
>>
>> Thanks, Jason
>>
>>
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
>
> --
> Kevin Broderick
> k...@kevinbroderick.com
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Request for review of plan for scripted edit

[Kevin Broderick]

I'm of mixed feelings on the apparent freshness, but as long as the
guidelines are followed so changesets are of reasonable size and easily
identified as scripted, I don't see much of an issue.

While having an automated script make assumptions caused me to twitch a
little, the reality is that a human is going to make the same assumption.
If I see a seven-digit number on a sign and want to dial it, I'm going to
assume that the area code is 207; if I'm across the state line in New
Hampshire, I'm going to assume 603. If that assumption isn't correct, the
source data is bad anyhow, and adding the implicit area code isn't making
it substantially worse. Have you been able to discern how many seven-digit
numbers are in the system?

On Thu, Aug 8, 2019 at 2:56 PM Jmapb  wrote:

> On 8/8/2019 1:28 PM, Alex Hennings wrote:
> > Community,
> >
> > I'm planning a scripted change and would like feedback. Plans are
> > outlined here:
> > https://wiki.openstreetmap.org/wiki/Automated_edits/blackboxlogic
> >
> > I'd appreciate feedback or questions in the 'Discussion' portion of
> > that wiki page, or within this email list.
>
> Hi Alex!
>
> First, a possible typo: I think "Nodes, Ways and References" should be
> "Nodes, Ways and Relations"?
>
> I'm a fan of the +1-xxx-xxx- format, since it's the only standard
> format that's visually intuitive to North American users. I often switch
> numbers to this format when I make updates to an existing POI.
>
> Personally, though, I've always felt a little uneasy about automated
> updates like this because they give a false impression of the freshness
> of the data. If it's been five years since any "real" updates to a POI,
> I'd rather that the date of last update reflected that. It's hard to
> gauge the community consensus on this issue, but IMO running this on
> POIs that have been manually updated (ie not by a mass edit) in the last
> 6 months would be fine.
>
> Regarding the single area code question... now that cell phones, VOIP,
> and nationwide calling plans are ubiquitous, the idea that a certain
> area code refers to a certain area is steadily eroding. I have started
> to see a few businesses with out-of-state phone numbers on their
> signs... but at this point it's still more likely that an out-of-state
> area code is an error or SEO spam. I'd suggest that these would go into
> your "Manually review or flag" category.
>
> Regardless, the idea that an area can have a single "traditional" area
> code is still true. Personally I have no problem with prepending the
> traditional area code onto 7-digit phone numbers. (I do it all the time
> in manual mapping.)
>
> Finally, thanks for posting your tools... I see these are written in
> CSharp, which I'm only tangentially familiar with. What sort of
> environment would one need to build these?
>
> Thanks, Jason
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


-- 
Kevin Broderick
k...@kevinbroderick.com
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-be] folk sports in Belgium

[joost schouppe]

You're right. Done.

Op wo 7 aug. 2019 om 00:53 schreef Lionel Giard :

> At the moment the OSM wiki page for sport=pelota only show the description
> of the "pelote basque " :
> https://wiki.openstreetmap.org/wiki/Tag%3Asport%3Dpelota . Maybe we
> should adapt the wiki description to show that this name "sport=pelota" is
> used for all regional variation ("basque pelota", "belgian pelota/balle
> pelote/kaatsen", ...) ? :-)
>
> Le mar. 6 août 2019 à 13:40, joost schouppe  a
> écrit :
>
>> Hi,
>>
>> After a bit of research, I retagged all "kaatspleinen" / "place de
>> pelotte" to sport=pelota. I think this is a decent tag for this. Folk
>> sports are hard, because there are local variants, and you have to decide
>> if you want to tag with the very specific local way of playing or keep it
>> simple and generalize a bit.
>>
>> I took advantage of the moment to create a little map of the 90 fields in
>> Belgium:
>>
>> https://www.mapcontrib.xyz/t/adc0b8-Folk_sports_in_Belgium#
>>
>> Which other sports should I add to that map?
>>
>> --
>> Joost Schouppe
>> OpenStreetMap  |
>> Twitter  | LinkedIn
>>  | Meetup
>> 
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>


-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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

Re: [Talk-us] Request for review of plan for scripted edit

[Jmapb]

On 8/8/2019 1:28 PM, Alex Hennings wrote:

Community,

I'm planning a scripted change and would like feedback. Plans are
outlined here:
https://wiki.openstreetmap.org/wiki/Automated_edits/blackboxlogic

I'd appreciate feedback or questions in the 'Discussion' portion of
that wiki page, or within this email list.


Hi Alex!

First, a possible typo: I think "Nodes, Ways and References" should be
"Nodes, Ways and Relations"?

I'm a fan of the +1-xxx-xxx- format, since it's the only standard
format that's visually intuitive to North American users. I often switch
numbers to this format when I make updates to an existing POI.

Personally, though, I've always felt a little uneasy about automated
updates like this because they give a false impression of the freshness
of the data. If it's been five years since any "real" updates to a POI,
I'd rather that the date of last update reflected that. It's hard to
gauge the community consensus on this issue, but IMO running this on
POIs that have been manually updated (ie not by a mass edit) in the last
6 months would be fine.

Regarding the single area code question... now that cell phones, VOIP,
and nationwide calling plans are ubiquitous, the idea that a certain
area code refers to a certain area is steadily eroding. I have started
to see a few businesses with out-of-state phone numbers on their
signs... but at this point it's still more likely that an out-of-state
area code is an error or SEO spam. I'd suggest that these would go into
your "Manually review or flag" category.

Regardless, the idea that an area can have a single "traditional" area
code is still true. Personally I have no problem with prepending the
traditional area code onto 7-digit phone numbers. (I do it all the time
in manual mapping.)

Finally, thanks for posting your tools... I see these are written in
CSharp, which I'm only tangentially familiar with. What sort of
environment would one need to build these?

Thanks, Jason



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

Re: [Talk-it] Quesito stabile nuovo da mappare

[Ivo Reano]

Stiamo facendo altro OT!
Il titolo è :
[Talk-it] Quesito stabile nuovo da mappare
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-us] Request for review of plan for scripted edit

[Alex Hennings]

Community,

I'm planning a scripted change and would like feedback. Plans are outlined
here:
https://wiki.openstreetmap.org/wiki/Automated_edits/blackboxlogic

I'd appreciate feedback or questions in the 'Discussion' portion of that
wiki page, or within this email list.

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

Re: [Talk-it] Quesito stabile nuovo da mappare

[scratera]

Ivo Reano wrote
> Martin, e tutti gli altri.
> Ma avete perso di vista la richiesta originale?
> Il "Gruppo Mòcheni 3.0" chiedeva lumi dai luminari sul modo corretto di
> mappare edifici. Non una incredibilmente lunga discussione sulla taggatura
> di poi e civici!
> Santa pazienza, se quei ragazzi seguono ancora il thread sono dei santi!
> 
> ___
> Talk-it mailing list

> Talk-it@

> https://lists.openstreetmap.org/listinfo/talk-it

...a dire il vero il post originale era per capire come mappare i sentieri
stravolti dalla tempesta vaia 



--
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-de] Oberfläche: paved, concrete, asphalt

[Harald Hartmann]

Ich hatte dazu mal in 2016 ein Auswertung gemacht und dazu auch einen
Diary-Eintrag samt Grafik hinterlassen:

https://www.openstreetmap.org/user/Harald%20Hartmann/diary/37965


Am 08.08.19 um 14:53 schrieb Martin Trautmann:
> Hallo,
> 
> auf maps.openrouteservice.org habe ich bei der Planung einer Strecke
> überwiegend auf Autobahnen überrascht festgestellt, dass tatsächlich oft
> asphalt oder paved genannt wird - eine überraschende Unterscheidung.
> Dann wundere ich mich aber wiederum, warum so wenig als concrete
> markiert ist.
> 
> Beruhen diese Kennzeichnungen tatsächlich auf Kenntnis des
> Fahrbahnbelags? Oder wird hier gewürfelt?
> 
> Denn gerade im Hochsommer mit Dehnungsproblemen bei Betonfahrbahnen mag
> die Unterscheidung interessant sein - aber sonst?
> 
> Schönen Gruß
> Martin
> 
> 
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
> 

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

Re: [Talk-de] Oberfläche: paved, concrete, asphalt

[Harald Hartmann]

>> Beruhen diese Kennzeichnungen tatsächlich auf Kenntnis des
>> Fahrbahnbelags? Oder wird hier gewürfelt?
> also paved ist schon man besser als nichts was man auf einer BAB angeben
> kann. Die Verfeinerung mit Asphalt oder Beton wäre natürlich optimal dann.

Ja, aber paved ist nur auf den wenigstens Teilabschnitten auch wirklich
so eingetragen ... siehe meine andere Antwort und meine Grafik von 2016
(ich glaube nicht, dass sich daran großartig etwas geändert hat)

>> Denn gerade im Hochsommer mit Dehnungsproblemen bei Betonfahrbahnen mag
>> die Unterscheidung interessant sein - aber sonst?
> Naja um die Unebenheit zu beschreiben wäre dann ja besser der key
> smoothness.

Rein theoretisch ja, aber eine Betonautobahn ist bei normalen Umständen
genauso smoothig wie eine Asphaltautobahn ... und für solch temporären
Ereignisse wie Blowups sollte es aber definitiv nicht verwendet werden.

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

Re: [OSM-talk-fr] Panneaux de signalisation manquant

[Jérôme Seigneuret]

C'est pas le distinguo qui m'intéresse. Le but étant de reprendre la
question posée au sénat et la réponse qui en découle. On risque de taguer
des classe de vitesse par erreur faute de signalisation adéquat. Ça a donc
sa place et répond à des problématiques routine déjà argumenté. Le fait de
pouvoir mentionner le problème permet d'en parler en effet avec les élus et
la PM. Le fais de parler de ça ainsi et ici c'est aussi de pouvoir
argumenter face aux différents services sur ces problèmes. Faut pas oublier
que fournir un référentiel ça engage aussi la responsabilité de celui qui
le fourni.

Le jeu. 8 août 2019 à 18:03,  a écrit :

> Faire le distingo public/privé ouvert au public, d'après tes références
> c'est clair, n'a aucun intérêt d'un point de vue OSM.
> Pouvoir arriver à entrer (ou sortir mais c'est moins grave) en
> agglomération sans panneau c'est effectivement un problème mais avant tout
> à signaler à la police municipale, aux services techniques ou à la mairie.
> Mais je doute que la vitesse maximale ne soit facilement déterminable : en
> principe la limite de l'agglomeration est visible. Cas général, il peut
> évidemment y avoir des cas particuliers.
>
> Jean-Yvon
>
>
> > Gesendet: Donnerstag, 08. August 2019 um 17:06 Uhr
> > Von: "Jérôme Seigneuret - jerome.seigneu...@gmail.com"
> > An: "Discussions sur OSM en français" 
> > Betreff: [OSM-talk-fr] Panneaux de signalisation manquant
> >
> > Pour faire suite à des discussions que nous avons entamé précédemment.
> > (Désolé de ne pas faire le lien avec les archives)
> >
> > *Conformément à l’article L. 2213-1 du Code général des collectivités
> > territoriales (CGCT  >),
> > le maire exerce à l’intérieur de l’agglomération la police de la
> > circulation « sur les routes nationales, les routes départementales et
> les
> > voies de communication ». Il convient d’entendre, par voies de
> > communication à l’intérieur des agglomérations, l’ensemble des voies
> > publiques ou privées ouvertes à la circulation publique.*
> >
> > *En outre, l’article L.2212-2 du CGCT prévoit que le maire dispose sur le
> > territoire de la commune de pouvoirs de police administrative qui
> > comprennent notamment « tout ce qui intéresse la sûreté et la commodité
> de
> > passage dans les rues, quais, places et voies publiques ».*
> >
> > *Sur le fondement de ces dispositions, le maire exerce son pouvoir de
> > police sur l’ensemble des voies ouvertes à la circulation publique, y
> > compris celles qui relèvent de propriétés privées, afin d’assurer la
> sûreté
> > et la commodité du passage (CE, 15 juin 1998, Commune de Claix, req. n°
> > 171786).*
> >
> > *L’inaction de l’autorité de police sur une voie privée ouverte à la
> > circulation publique, en l’espèce l’absence de signalisation et
> d’éclairage
> > nécessaires pour signaler une palissade, est de nature à engager la
> > responsabilité de la commune en cas d’accident survenu à un tiers (CE, 8
> > mai 1963, commune de Maisons-Laffitte).*
> >
> >
> > *Or, en vertu de l’article R.411-25 du Code de la route, les dispositions
> > prises par l’autorité investie du pouvoir de police doivent faire l’objet
> > de mesures de signalisation pour être opposables aux
> > usagers. L’installation de panneaux de limitation de vitesse sur une voie
> > privée ouverte à la circulation publique relève ainsi des obligations
> > législatives et réglementaires précitées de l’autorité municipale et ne
> > peuvent être mises à la charge des propriétaires.*
> >
> > *De manière générale, il convient de préciser que l’autorité de police
> > municipale ne peut pas mettre à la charge de propriétaires privés la
> > réalisation de travaux lorsque ces travaux ont un intérêt collectif et ne
> > sont pas la conséquence de la méconnaissance par les propriétaires
> > d’obligations qui leur incombent (CE, 6 avril 1998, req. n° 142845 ; CAA
> > Bordeaux, 30 avril 2002, req. n° 99BX01216).*
> >
> > On ne parle pas globalement des conséquence de l'abscence d'un panneau
> > d'entrée ou sortie d'agglomération mais que l’absence de signalisation
> > claire entraîne la responsabilité de la commune.
> >
> > Si l'on peut dire que la signalisation sur voie privée doit être faite au
> > frais de la commune dans certains cas, je pense que l'on peut considérer
> > qu'une sortie de ville sur un chemin carrossable doit faire l'objet de ce
> > genre de signalisation. Ainsi éviter un accident lié à la vitesse surtout
> > sur l'entrée de ville. Si la vitesse est prise comme motif de l'accident
> ce
> > sera la commune qui sera responsable.
> >
> > Bref pour le moment je vais faire des notes:
> >
> > vous pensez quoi de ça :
> >
> >
> >
> > note=#highwayspeedconflict + maxspeed=50;80 +
> > source:maxspeed=FR:urban;FR:rural
> > --
> > Cordialement,
> > Jérôme Seigneuret
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > 

Re: [OSM-talk-fr] Panneaux de signalisation manquant

[osm . sanspourriel]

Faire le distingo public/privé ouvert au public, d'après tes références c'est 
clair, n'a aucun intérêt d'un point de vue OSM.
Pouvoir arriver à entrer (ou sortir mais c'est moins grave) en agglomération 
sans panneau c'est effectivement un problème mais avant tout à signaler à la 
police municipale, aux services techniques ou à la mairie.
Mais je doute que la vitesse maximale ne soit facilement déterminable : en 
principe la limite de l'agglomeration est visible. Cas général, il peut 
évidemment y avoir des cas particuliers.

Jean-Yvon


> Gesendet: Donnerstag, 08. August 2019 um 17:06 Uhr
> Von: "Jérôme Seigneuret - jerome.seigneu...@gmail.com"
> An: "Discussions sur OSM en français" 
> Betreff: [OSM-talk-fr] Panneaux de signalisation manquant
>
> Pour faire suite à des discussions que nous avons entamé précédemment.
> (Désolé de ne pas faire le lien avec les archives)
> 
> *Conformément à l’article L. 2213-1 du Code général des collectivités
> territoriales (CGCT ),
> le maire exerce à l’intérieur de l’agglomération la police de la
> circulation « sur les routes nationales, les routes départementales et les
> voies de communication ». Il convient d’entendre, par voies de
> communication à l’intérieur des agglomérations, l’ensemble des voies
> publiques ou privées ouvertes à la circulation publique.*
> 
> *En outre, l’article L.2212-2 du CGCT prévoit que le maire dispose sur le
> territoire de la commune de pouvoirs de police administrative qui
> comprennent notamment « tout ce qui intéresse la sûreté et la commodité de
> passage dans les rues, quais, places et voies publiques ».*
> 
> *Sur le fondement de ces dispositions, le maire exerce son pouvoir de
> police sur l’ensemble des voies ouvertes à la circulation publique, y
> compris celles qui relèvent de propriétés privées, afin d’assurer la sûreté
> et la commodité du passage (CE, 15 juin 1998, Commune de Claix, req. n°
> 171786).*
> 
> *L’inaction de l’autorité de police sur une voie privée ouverte à la
> circulation publique, en l’espèce l’absence de signalisation et d’éclairage
> nécessaires pour signaler une palissade, est de nature à engager la
> responsabilité de la commune en cas d’accident survenu à un tiers (CE, 8
> mai 1963, commune de Maisons-Laffitte).*
> 
> 
> *Or, en vertu de l’article R.411-25 du Code de la route, les dispositions
> prises par l’autorité investie du pouvoir de police doivent faire l’objet
> de mesures de signalisation pour être opposables aux
> usagers. L’installation de panneaux de limitation de vitesse sur une voie
> privée ouverte à la circulation publique relève ainsi des obligations
> législatives et réglementaires précitées de l’autorité municipale et ne
> peuvent être mises à la charge des propriétaires.*
> 
> *De manière générale, il convient de préciser que l’autorité de police
> municipale ne peut pas mettre à la charge de propriétaires privés la
> réalisation de travaux lorsque ces travaux ont un intérêt collectif et ne
> sont pas la conséquence de la méconnaissance par les propriétaires
> d’obligations qui leur incombent (CE, 6 avril 1998, req. n° 142845 ; CAA
> Bordeaux, 30 avril 2002, req. n° 99BX01216).*
> 
> On ne parle pas globalement des conséquence de l'abscence d'un panneau
> d'entrée ou sortie d'agglomération mais que l’absence de signalisation
> claire entraîne la responsabilité de la commune.
> 
> Si l'on peut dire que la signalisation sur voie privée doit être faite au
> frais de la commune dans certains cas, je pense que l'on peut considérer
> qu'une sortie de ville sur un chemin carrossable doit faire l'objet de ce
> genre de signalisation. Ainsi éviter un accident lié à la vitesse surtout
> sur l'entrée de ville. Si la vitesse est prise comme motif de l'accident ce
> sera la commune qui sera responsable.
> 
> Bref pour le moment je vais faire des notes:
> 
> vous pensez quoi de ça :
> 
> 
> 
> note=#highwayspeedconflict + maxspeed=50;80 +
> source:maxspeed=FR:urban;FR:rural
> -- 
> Cordialement,
> Jérôme Seigneuret
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

[Talk-GB] In the news today....

[Jez Nicholson]

50 years ago, this zebra crossing was about to become the most famous in
Britain https://www.openstreetmap.org/node/1362022750
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[OSM-talk-fr] Panneaux de signalisation manquant

[Jérôme Seigneuret]

Pour faire suite à des discussions que nous avons entamé précédemment.
(Désolé de ne pas faire le lien avec les archives)

*Conformément à l’article L. 2213-1 du Code général des collectivités
territoriales (CGCT ),
le maire exerce à l’intérieur de l’agglomération la police de la
circulation « sur les routes nationales, les routes départementales et les
voies de communication ». Il convient d’entendre, par voies de
communication à l’intérieur des agglomérations, l’ensemble des voies
publiques ou privées ouvertes à la circulation publique.*

*En outre, l’article L.2212-2 du CGCT prévoit que le maire dispose sur le
territoire de la commune de pouvoirs de police administrative qui
comprennent notamment « tout ce qui intéresse la sûreté et la commodité de
passage dans les rues, quais, places et voies publiques ».*

*Sur le fondement de ces dispositions, le maire exerce son pouvoir de
police sur l’ensemble des voies ouvertes à la circulation publique, y
compris celles qui relèvent de propriétés privées, afin d’assurer la sûreté
et la commodité du passage (CE, 15 juin 1998, Commune de Claix, req. n°
171786).*

*L’inaction de l’autorité de police sur une voie privée ouverte à la
circulation publique, en l’espèce l’absence de signalisation et d’éclairage
nécessaires pour signaler une palissade, est de nature à engager la
responsabilité de la commune en cas d’accident survenu à un tiers (CE, 8
mai 1963, commune de Maisons-Laffitte).*


*Or, en vertu de l’article R.411-25 du Code de la route, les dispositions
prises par l’autorité investie du pouvoir de police doivent faire l’objet
de mesures de signalisation pour être opposables aux
usagers. L’installation de panneaux de limitation de vitesse sur une voie
privée ouverte à la circulation publique relève ainsi des obligations
législatives et réglementaires précitées de l’autorité municipale et ne
peuvent être mises à la charge des propriétaires.*

*De manière générale, il convient de préciser que l’autorité de police
municipale ne peut pas mettre à la charge de propriétaires privés la
réalisation de travaux lorsque ces travaux ont un intérêt collectif et ne
sont pas la conséquence de la méconnaissance par les propriétaires
d’obligations qui leur incombent (CE, 6 avril 1998, req. n° 142845 ; CAA
Bordeaux, 30 avril 2002, req. n° 99BX01216).*

On ne parle pas globalement des conséquence de l'abscence d'un panneau
d'entrée ou sortie d'agglomération mais que l’absence de signalisation
claire entraîne la responsabilité de la commune.

Si l'on peut dire que la signalisation sur voie privée doit être faite au
frais de la commune dans certains cas, je pense que l'on peut considérer
qu'une sortie de ville sur un chemin carrossable doit faire l'objet de ce
genre de signalisation. Ainsi éviter un accident lié à la vitesse surtout
sur l'entrée de ville. Si la vitesse est prise comme motif de l'accident ce
sera la commune qui sera responsable.

Bref pour le moment je vais faire des notes:

vous pensez quoi de ça :



note=#highwayspeedconflict + maxspeed=50;80 +
source:maxspeed=FR:urban;FR:rural
-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Track -> Chemin rural

[marc marc]

Le 08.08.19 à 15:53, pepilepi...@ovh.fr a écrit :
> LE gros problème, c'est que nous discutons entre français, avec nos 
> habitudes et notre expérience françaises, sur une terminologie et une 
> classification fortement marquées par les américains.

si cela te rassure, le hasard fait qu'il y a en ce moment le même genre 
de discussion sur la ml tagging mondiale.

par ailleurs unclassified das osm, c'est de l'anglais britannique :)
et non américain.
c'est le 4ieme niveau hiérarchique de route, en dessous de tertiaire

quelqu'un peux résumer les avis d'ici ?

les avis sur tagging sont (à mes risques et périls vu le nombre
de messages) :
- certains ont confondu unclassified avec inconnu (highway=road).
après échange, ils ont corrigés le tir.
- certains ont confondu unclassified avec "sans classification".
certains sont d'accord que c'était une erreur. d'autres "auteurs"
de cette erreur ne sont pas là pour en discuter.
- il semble y avoir un assez grand nombre pour insister sur le fait
que unclassified est un type de voie non minuscule, utilisé pour le 
transit entre hameau, voie principale dans une zone industrielle,
voie rurale de liaison entre zone résidentielle.
le point "d’achoppement" actuel et que certains voudraient que
unclassified soie mieux "mis au dessus" de residentiel.
puisque des unclassied semblent exister au UK en pleine zone 
résidentielle (ndlr : je prend des pincettes par manque d'exemple
simple dans les échanges), cela aurait du sens, même si en France,
la décentralisation a rendu bancal la classification historique
- pas grand monde voire personne sur tagging ne semble avoir un soucis
de différentiation entre track et les autres.
track à mes yeux est hors "réseau routier", c'est un chemin agricole, 
forestrier, agriculture, loisir (parc). c'est typiquement le chemin que
vous ne prenez jamais en voiture malgré que la largeur le permet
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Quesito stabile nuovo da mappare

[Ivo Reano]

Allora, secondo netiquette, si deve aprire un nuovo thread.
Lo dico per chi segue da poco la ML. I vecchi dovrebbero saperlo.

Il giorno gio 8 ago 2019 alle ore 16:01 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

>
>
> sent from a phone
>
> On 8. Aug 2019, at 15:36, Ivo Reano  wrote:
>
> Non una incredibilmente lunga discussione sulla taggatura di poi e civici!
> Santa pazienza, se quei ragazzi seguono ancora il thread sono dei santi!
>
>
>
> è vero che non ci rivolgiamo più soprattutto ai ragazzi e siamo invece
> discutendo tra “mappatori anziani” i problemi generali della mappatura dei
> civici. Questo perché ci sono dei dogmi in giro che portano ad una perdita
> di informazioni (indirizzi dei POI), e che prima o poi saranno risolti,
> spero.
>
> Ciao Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Track -> Chemin rural

[Jérôme Seigneuret]

@JB c'est bien pour cela qu'il faut contextualiser avec nos propres besoins
de classification sans caser le système. Pour moi beaucoup trop de voies
sont classées en highway=unclassified sans raison apparente.

Il y a une discussion en parallèle sur la list tagging en lien avec la
hiérarchisation des voies.

Un track n'est pas une piste comme je le précise dans mes précédents mails.
Un track de type grade 3 voir 4 et plus je peux dire oui et encore car une
piste n'est normalement pas accessible aux véhicules lambda.
D'où le fait de bien mettre le type de grade
Les chemins vicinaux en France, comme tu le mentionnes, sont à 80%
carrossées sauf sur les zones très agricoles ou montagneuses dont la
communes s'est portées acquéreuse des voies (bien commun pour l'accès au
parcelles) certaines de ces chemins ne permettent d'ailleurs pas l'accès à
des véhicules sauf motocross ou trial

Quand vous arrivez là-dessus avec une bonne Camaro des années 70, je vous
laisse deviner la surprise...
Humm les joies de la propultion sur sol glissant

Je vais faire une tentative avec les zones que je connais bien dans la
semaine pour corriger des classements et présenter un peu les zones en
avant après et le comportement sur les outils de routing existant.
Histoire de pas avoir du revert à Gogo:
- Lunel et périphérie (ville avec des mas transformés ou non en résidence)
- Tavel et communes voisines (zones de villages avec peu d'écart)


Le jeu. 8 août 2019 à 15:54, pepilepi...@ovh.fr  a
écrit :

> Le 08/08/2019 à 13:49, Stéphane Péneau a écrit :
>
> Le gros problème de toute cette discussion, c'est qu'il n'y a pas
> d'exemple, de lien vers un highway d'Osm.
>
> Non.
>
> LE gros problème, c'est que nous discutons entre français, avec nos
> habitudes et notre expérience françaises, sur une terminologie et une
> classification fortement marquées par les américains.
>
> Aux État-Unis il y a des routes relativement importantes qui ne sont pas
> goudronnées. Un jour j'avais raconté à un copain que j'étais allé me
> promener "sur la piste qui suit la rivière
> ";
> il m'a vertement rabroué en m'expliquant "ça s'appelle une route".
>
> Moi, j'appelais ça "une piste" ("a track") à la lumière de mon expérience
> française.
>
> En France, à 99,9 %, si c'est pas goudronné, c'est un "track". Ou un
> "driveway", surtout vers les fermes. Le moindre "unclassified" est revêtu.
> Mal, souvent, mais revêtu.
>
> 
>
> Il y a aussi quelques différences culturelles bonnes à connaître. Les
> riverains de cette route / piste en terre gravillonnée avaient l'habitude,
> pour éviter que le passage des véicules ne soulève beaucoup de poussière,
> de l'asperger d'huile. Quand vous arrivez là-dessus avec une bonne Camaro
> des années 70, je vous laisse deviner la surprise...
>
> 
>
> Bonne journée,
>
> JP
>
>
>
> Le 08/08/2019 à 11:53, Jérôme Seigneuret a écrit :
>
>
> Du coup highway unclassified reste sur les occupations non résidentielle
> et hors système forestier et bocager, en landuse residentiel c'est
> highway=residentiel qui prime et dans les systèmes ruraux (sauf route
> principale) ce sont des chemins ou voies donc track. Après c'est le
> tracktype et son grade qui compte.
>
> Donc, pour toi ceci devrait être un track ?
>
> https://www.openstreetmap.org/way/112796056
>
>
> highway=service+service=alley pour le wiki français est un chemin servant
> à desservir un groupe de résidences.
>
> Ce n'est pas de cette façon que je lis le wiki.
>
> Exemple, pour toi, ceci serait un service=alley ?
>
> https://www.openstreetmap.org/way/133901363
>
>
> Stf
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
> --
> --
>
> Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
> bonne question
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [Talk-se] Lantmäteriets öppna data

[Eva Lindberg]

Jag måste rätta det jag skrev om höjdkurvor. Jag läste dokumentationen 
och de är analogt sterokarterade, alltså inte från nationella 
höjdmodellen. Men de är ändå bättre än de höjdkurvor som finns i OSM där 
jag har kollat.


On 2019-08-08 16:08, Eva Lindberg wrote:

Hej! När det gäller ytor har jag skrivit att jag inte tror att
terrängkartan är den bästa källan, i alla fall för skog och annan
natur. De markklasser som jag tror kan vara användbara i terrängkartan
är tätbebyggt område, industriområde och vatten.

Det borde dock vara ovanligt att det finns skog som står som åker på
terrängkartan, terrängkartan kommer från Lantmäteriets basdata och det
uppdateras när nya flygfoton kommer vilket är vart 2-4 år beroende på
var i landet man är.

Nu förstår jag vad du menar med att en del objekt ligger på fel
ställe. Det är alltså pga att terrängkartan är ritad för att gå bra
att läsa. När det gäller stora vägar är kanske Trafikverkets karta
bättre och den är väl redan på gång att läggas in eller har lagts in
om jag fattar rätt.

Men det finns information där terrängkartan är den bästa källan:
-Stigar eller traktorvägar som du skriver
-De flesta ortsnamn och terrängnamn
-Höjdkurvor finns med 5 m intervall och kommer förmodligen från den
nationella höjdmodellen som är mycket noggrann. Även
höjdangivelser/siffror finns.
-Bäckar samt att storleken på vattendrag är mer korrekt i
terrängkartan än nuvarande OSM där jag har kollat
-Vändplaner och vägbommar finns med, det hittar jag inte i 
Trafikverkets data

-Kraftledningar, viktigt för att orientera sig i terräng
-Byggnader utanför tätort, både stora och mindre hus/gårdar.

Fornminnen är en annan sak, det skulle jag helst ta från
Riksantikvarieämbetets öppna data.



On 2019-08-08 14:13, Christian Asker wrote:

Hej. Terrängkartan är lite knepig eftersom själva datat är anpassat
för att objekt inte ska ligga ovanpå varandra för mycket (så att
kartan blir för plottrig). Det innebär att en del objekts positioner
har justerats. Tex vägar kan ligga 10 meter fel jämfört med
Trafikverkets data.

Ytor (som skog tex) består dessutom av väldigt stora multipolygoner,
som är svåra att hantera. När jag försökte att importera Terrängkartan
upplevde jag att det var mindre jobb att helt enkelt rita ytor för
hand utifrån flyg-/satellit-foton. Dessutom stämmer inte alltid
markanvändningen i Terrängkartan med verkligheten; i de områden jag
har provat har en hel del åkermark blivit skog under de senaste
decennierna och Terrängkartan verkar inte ha uppdaterats...

I slutändan har jag mest importerat traktorvägar, lite stigar,
fornlämningar och liknande från Terrängkartan; resten har visat sig
inte vara mödan värt. Detta är dock bara min personliga åsikt; det kan
ju hända att någon som är mer GIS-kompetent än jag har andra
erfarenhetet.


Jag har skrivit lite om det här i min OSM-dagbok:
https://www.openstreetmap.org/user/ChristianA/diary/43315

Där kan du även se bilder som förklarar vad jag menar.


Mvh ChristianA



Den 2019-08-08 kl. 13:41, skrev Eva Lindberg:
Tack för svar! Dessa inlägg hade jag inte sett. Har diskussionen 
fortsatt senare?


Som jag skrev nedan tror jag också att NMD är bättre än terrängkartan 
för markklasser. Framförallt för att den är gjord för att klassa mark 
medan det blir lite konstigt med markklasser i vektorformat av 
orsaker som togs upp i tråden som du länkade till. Dessutom är NMD 
bra för att den har fler klasser än de som finns i terrängkartan. 
Nackdelar med NMD är som någon tog upp dels att en klass som tex skog 
kan ha hål eftersom enstaka fläckar blir klassade som något annat och 
dels felklassning som kan bli bättre med manuella metoder vilket 
ligger till grund för tex terrängkartan. Sedan har ju NMD fördelen 
att den kan uppdateras regelbundet medan terrängkartan kan ha fel pga 
att data är föråldrade.


Men det jag är ute efter är framförallt vektorobjekt som vägar, hus 
och vattendrag som finns i terrängkartan. Det finns stora områden i 
Sverige som inte är karterade alls i OSM och där skulle de hjälpa.


MVH /Eva

On 2019-08-08 12:40, Karl-Johan Karlsson wrote:

Terrängkartan har diskuterats lite tidigare. Se:
https://lists.openstreetmap.org/pipermail/talk-se/2019-April/003651.html

Den tors 8 aug. 2019 kl 12:00 skrev Eva Lindberg 
:



Jag är ny användare här och anledningen att jag är intresserad
av OSM är
att jag vill ha en bra karta för ett visst område i norra Sverige.

Området verkar just nu inte vara karterat överhuvudtaget. Det är
här:
https://www.openstreetmap.org/#map=12/63.5201/17.9881

Jag har lite koll på GIS och kartor och tycker att ett effektivt
sätt
att få in grundläggande kartor för området skulle vara att
importera
Lantmäteriets öppna data, speciellt terrängkartan. Jag förstår
att det
kräver dels att användarna av OSM vill ha in det och dels att man
kollar
kollisioner vid importen så att man inte förstör något som redan
är
karterat. Eftersom Lantmäteriets kartor finns för hela landet
undrar jag
om man skulle kunna ta ett 

Re: [Talk-se] Lantmäteriets öppna data

[Eva Lindberg]

Hej! När det gäller ytor har jag skrivit att jag inte tror att 
terrängkartan är den bästa källan, i alla fall för skog och annan natur. 
De markklasser som jag tror kan vara användbara i terrängkartan är 
tätbebyggt område, industriområde och vatten.


Det borde dock vara ovanligt att det finns skog som står som åker på 
terrängkartan, terrängkartan kommer från Lantmäteriets basdata och det 
uppdateras när nya flygfoton kommer vilket är vart 2-4 år beroende på 
var i landet man är.


Nu förstår jag vad du menar med att en del objekt ligger på fel ställe. 
Det är alltså pga att terrängkartan är ritad för att gå bra att läsa. 
När det gäller stora vägar är kanske Trafikverkets karta bättre och den 
är väl redan på gång att läggas in eller har lagts in om jag fattar 
rätt.


Men det finns information där terrängkartan är den bästa källan:
-Stigar eller traktorvägar som du skriver
-De flesta ortsnamn och terrängnamn
-Höjdkurvor finns med 5 m intervall och kommer förmodligen från den 
nationella höjdmodellen som är mycket noggrann. Även 
höjdangivelser/siffror finns.
-Bäckar samt att storleken på vattendrag är mer korrekt i terrängkartan 
än nuvarande OSM där jag har kollat
-Vändplaner och vägbommar finns med, det hittar jag inte i Trafikverkets 
data

-Kraftledningar, viktigt för att orientera sig i terräng
-Byggnader utanför tätort, både stora och mindre hus/gårdar.

Fornminnen är en annan sak, det skulle jag helst ta från 
Riksantikvarieämbetets öppna data.




On 2019-08-08 14:13, Christian Asker wrote:

Hej. Terrängkartan är lite knepig eftersom själva datat är anpassat
för att objekt inte ska ligga ovanpå varandra för mycket (så att
kartan blir för plottrig). Det innebär att en del objekts positioner
har justerats. Tex vägar kan ligga 10 meter fel jämfört med
Trafikverkets data.

Ytor (som skog tex) består dessutom av väldigt stora multipolygoner,
som är svåra att hantera. När jag försökte att importera Terrängkartan
upplevde jag att det var mindre jobb att helt enkelt rita ytor för
hand utifrån flyg-/satellit-foton. Dessutom stämmer inte alltid
markanvändningen i Terrängkartan med verkligheten; i de områden jag
har provat har en hel del åkermark blivit skog under de senaste
decennierna och Terrängkartan verkar inte ha uppdaterats...

I slutändan har jag mest importerat traktorvägar, lite stigar,
fornlämningar och liknande från Terrängkartan; resten har visat sig
inte vara mödan värt. Detta är dock bara min personliga åsikt; det kan
ju hända att någon som är mer GIS-kompetent än jag har andra
erfarenhetet.


Jag har skrivit lite om det här i min OSM-dagbok:
https://www.openstreetmap.org/user/ChristianA/diary/43315

Där kan du även se bilder som förklarar vad jag menar.


Mvh ChristianA



Den 2019-08-08 kl. 13:41, skrev Eva Lindberg:
Tack för svar! Dessa inlägg hade jag inte sett. Har diskussionen 
fortsatt senare?


Som jag skrev nedan tror jag också att NMD är bättre än terrängkartan 
för markklasser. Framförallt för att den är gjord för att klassa mark 
medan det blir lite konstigt med markklasser i vektorformat av orsaker 
som togs upp i tråden som du länkade till. Dessutom är NMD bra för att 
den har fler klasser än de som finns i terrängkartan. Nackdelar med 
NMD är som någon tog upp dels att en klass som tex skog kan ha hål 
eftersom enstaka fläckar blir klassade som något annat och dels 
felklassning som kan bli bättre med manuella metoder vilket ligger 
till grund för tex terrängkartan. Sedan har ju NMD fördelen att den 
kan uppdateras regelbundet medan terrängkartan kan ha fel pga att data 
är föråldrade.


Men det jag är ute efter är framförallt vektorobjekt som vägar, hus 
och vattendrag som finns i terrängkartan. Det finns stora områden i 
Sverige som inte är karterade alls i OSM och där skulle de hjälpa.


MVH /Eva

On 2019-08-08 12:40, Karl-Johan Karlsson wrote:

Terrängkartan har diskuterats lite tidigare. Se:
https://lists.openstreetmap.org/pipermail/talk-se/2019-April/003651.html

Den tors 8 aug. 2019 kl 12:00 skrev Eva Lindberg :


Jag är ny användare här och anledningen att jag är intresserad
av OSM är
att jag vill ha en bra karta för ett visst område i norra Sverige.

Området verkar just nu inte vara karterat överhuvudtaget. Det är
här:
https://www.openstreetmap.org/#map=12/63.5201/17.9881

Jag har lite koll på GIS och kartor och tycker att ett effektivt
sätt
att få in grundläggande kartor för området skulle vara att
importera
Lantmäteriets öppna data, speciellt terrängkartan. Jag förstår
att det
kräver dels att användarna av OSM vill ha in det och dels att man
kollar
kollisioner vid importen så att man inte förstör något som redan
är
karterat. Eftersom Lantmäteriets kartor finns för hela landet
undrar jag
om man skulle kunna ta ett större grepp så att det finns struktur
för
att lägga in kartorna för andra områden om någon vill.

Jag hittar ingen större diskussion om Lantmäteriets öppna data
varken
här, på forumet eller på wikin. Har det diskuterats och vad har i
så
fall kommit 

Re: [Talk-it] Quesito stabile nuovo da mappare

[Martin Koppenhoefer]

sent from a phone

> On 8. Aug 2019, at 15:36, Ivo Reano  wrote:
> 
> Non una incredibilmente lunga discussione sulla taggatura di poi e civici!
> Santa pazienza, se quei ragazzi seguono ancora il thread sono dei santi!


è vero che non ci rivolgiamo più soprattutto ai ragazzi e siamo invece 
discutendo tra “mappatori anziani” i problemi generali della mappatura dei 
civici. Questo perché ci sono dei dogmi in giro che portano ad una perdita di 
informazioni (indirizzi dei POI), e che prima o poi saranno risolti, spero.

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

Re: [OSM-talk-fr] Track -> Chemin rural

[pepilepi...@ovh.fr]

Le 08/08/2019 à 13:49, Stéphane Péneau a écrit :
> Le gros problème de toute cette discussion, c'est qu'il n'y a pas
> d'exemple, de lien vers un highway d'Osm.

Non.

LE gros problème, c'est que nous discutons entre français, avec nos
habitudes et notre expérience françaises, sur une terminologie et une
classification fortement marquées par les américains.

Aux État-Unis il y a des routes relativement importantes qui ne sont pas
goudronnées. Un jour j'avais raconté à un copain que j'étais allé me
promener "sur la piste qui suit la rivière
";
il m'a vertement rabroué en m'expliquant "ça s'appelle une route".

Moi, j'appelais ça "une piste" ("a track") à la lumière de mon
expérience française.

En France, à 99,9 %, si c'est pas goudronné, c'est un "track". Ou un
"driveway", surtout vers les fermes. Le moindre "unclassified" est
revêtu. Mal, souvent, mais revêtu.



Il y a aussi quelques différences culturelles bonnes à connaître. Les
riverains de cette route / piste en terre gravillonnée avaient
l'habitude, pour éviter que le passage des véicules ne soulève beaucoup
de poussière, de l'asperger d'huile. Quand vous arrivez là-dessus avec
une bonne Camaro des années 70, je vous laisse deviner la surprise...



Bonne journée,

JP

>
>
> Le 08/08/2019 à 11:53, Jérôme Seigneuret a écrit :
>>
>> Du coup highway unclassified reste sur les occupations non
>> résidentielle et hors système forestier et bocager, en landuse
>> residentiel c'est highway=residentiel qui prime et dans les systèmes
>> ruraux (sauf route principale) ce sont des chemins ou voies donc
>> track. Après c'est le tracktype et son grade qui compte.
>>
> Donc, pour toi ceci devrait être un track ?
>
> https://www.openstreetmap.org/way/112796056
>
>
>> highway=service+service=alley pour le wiki français est un chemin
>> servant à desservir un groupe de résidences.
>>
> Ce n'est pas de cette façon que je lis le wiki.
>
> Exemple, pour toi, ceci serait un service=alley ?
>
> https://www.openstreetmap.org/way/133901363
>
>
> Stf
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


-- 


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


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

Re: [OSM-talk-fr] Track -> Chemin rural

[Jérôme Seigneuret]

Exacte et c'est là bien le problème car la définition et l'emploi de cette
clé est fait par défaut car la taille du rendu est supérieur à celle d'un
driveway. Mais un driveway c'est uniquement pour l'accès terminal pour un
batiment donc le dernier tronçon ou la dernière fourche. Un peu comme
parking_aisle. Pour un petit parking à une ou deux voies on peut laisser
service=parking_aisle ou les voies de service servant à dirriger le traffic
vers les entrée sortie on ne met pas cette clé.

Le jeu. 8 août 2019 à 15:12, marc marc  a écrit :

> Le 08.08.19 à 14:57, Rpnpif a écrit :
> > Le  8 août 2019, Jérôme Seigneuret a écrit :
> >
> >> Sur la page général alley c'est
> >> pour le chemin secondaire des résidences ou voies étroites en zone
> >> européenne pour les centre de type médiévaux...
> >
> > En dehors de ce cas je préfère service=driveway qui me semble plus
> > adapté (allée en français). Alley signifie ruelle.
>
> oui de ce que j'en ai compris, c'est la ruelle "arrière" situé
> entre 2 rangées de maisons et d'utilisation technique (garage, poubelle).
> faux ami totalement opposé avec une belle allée :)
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [Talk-it] Quesito stabile nuovo da mappare

[Ivo Reano]

Martin, e tutti gli altri.
Ma avete perso di vista la richiesta originale?
Il "Gruppo Mòcheni 3.0" chiedeva lumi dai luminari sul modo corretto di
mappare edifici. Non una incredibilmente lunga discussione sulla taggatura
di poi e civici!
Santa pazienza, se quei ragazzi seguono ancora il thread sono dei santi!
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] Oberfläche: paved, concrete, asphalt

[Martin Scholtes]

Hallo,

Am 08.08.2019 um 14:53 schrieb Martin Trautmann:
> Beruhen diese Kennzeichnungen tatsächlich auf Kenntnis des
> Fahrbahnbelags? Oder wird hier gewürfelt?
also paved ist schon man besser als nichts was man auf einer BAB angeben
kann. Die Verfeinerung mit Asphalt oder Beton wäre natürlich optimal dann.
> Denn gerade im Hochsommer mit Dehnungsproblemen bei Betonfahrbahnen mag
> die Unterscheidung interessant sein - aber sonst?
Naja um die Unebenheit zu beschreiben wäre dann ja besser der key
smoothness.

-- 
Mit freundlichen Grüßen


Martin Scholtes


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

Re: [Talk-de] Oberfläche: paved, concrete, asphalt

[Martin Koppenhoefer]

sent from a phone

> On 8. Aug 2019, at 14:53, Martin Trautmann  wrote:
> 
> Denn gerade im Hochsommer mit Dehnungsproblemen bei Betonfahrbahnen mag
> die Unterscheidung interessant sein - aber sonst?


m.E. sollte man sofern man es weiß, paved und unpaved in einen konkreteren Wert 
ändern, andersrum hingegen nicht.


Gruß Martin 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk-fr] Track -> Chemin rural

[marc marc]

Le 08.08.19 à 14:57, Rpnpif a écrit :
> Le  8 août 2019, Jérôme Seigneuret a écrit :
> 
>> Sur la page général alley c'est
>> pour le chemin secondaire des résidences ou voies étroites en zone
>> européenne pour les centre de type médiévaux...
> 
> En dehors de ce cas je préfère service=driveway qui me semble plus
> adapté (allée en français). Alley signifie ruelle.

oui de ce que j'en ai compris, c'est la ruelle "arrière" situé
entre 2 rangées de maisons et d'utilisation technique (garage, poubelle).
faux ami totalement opposé avec une belle allée :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Quesito stabile nuovo da mappare

[Martin Koppenhoefer]

sent from a phone

> On 8. Aug 2019, at 12:21, Federico Cortese  wrote:
> 
> Queste difformità sono dovute a situazioni precedenti alla normativa
> ISTAT che è abbastanza recente ed è stata scritta proprio per
> risolvere questi problemi e creare uniformità.



„recente“ per i tempi della PA? Non sono stati introdotti prima dell’ultimo 
censimento nazionale circa un decennio fa? Si tratta di un progetto secolare?



> Inoltre gli uffici toponomastica dei comuni stanno progressivamente
> ponendo rimedio, adeguandosi a quanto richiesto da ISTAT.


noi rileviamo la realtà in loco. Non ci interessa se la numerazione esistente 
(e inesistente) è a norma o meno, stiamo rilevando ciò che esiste adesso, non 
dobbiamo capire come dovrebbe essere.

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

Re: [OSM-talk-fr] Track -> Chemin rural

[Rpnpif]

Le  8 août 2019, Jérôme Seigneuret a écrit :

> Sur la page général alley c'est
> pour le chemin secondaire des résidences ou voies étroites en zone
> européenne pour les centre de type médiévaux...

En dehors de ce cas je préfère service=driveway qui me semble plus
adapté (allée en français). Alley signifie ruelle.
Si je me souviens bien, il y a une alerte Osmose là-dessus.

-- 
Alain Rpnpif

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

[Talk-de] Oberfläche: paved, concrete, asphalt

[Martin Trautmann]

Hallo,

auf maps.openrouteservice.org habe ich bei der Planung einer Strecke
überwiegend auf Autobahnen überrascht festgestellt, dass tatsächlich oft
asphalt oder paved genannt wird - eine überraschende Unterscheidung.
Dann wundere ich mich aber wiederum, warum so wenig als concrete
markiert ist.

Beruhen diese Kennzeichnungen tatsächlich auf Kenntnis des
Fahrbahnbelags? Oder wird hier gewürfelt?

Denn gerade im Hochsommer mit Dehnungsproblemen bei Betonfahrbahnen mag
die Unterscheidung interessant sein - aber sonst?

Schönen Gruß
Martin



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

Re: [OSM-talk-fr] Track -> Chemin rural

[Jérôme Seigneuret]

@Stf
Pour le cas du chemin rural oui je garderai que la D56. La page du wwiki
anglais voudrais que l'on mettent unclassified pour des maillage du reseau
permettant la connexion entre de petits ensemble bati. residential pour des
route dont la vitesse est limité à cause de la présence de bati
donc l'interconnexion entre des zones residentiel peut se faire en
unclassified car ça répond au besoin de maillage.
La différence c'est que chez nous le maillage est très important et que
l'on est loin d'avoir besoin de claaser toutes les route avec ce type.
unclassified doit être employé sur des routes rural du maillage urbain (un
cas que j'ai pas explicité précédemment) qui ne sont pas de type tertiairy.
Donc si l'on reprends mon message précédent, il me semble que la plupart
des connexions entre villages sont déjà de type départementaux (c'est le
cas dans le 30 et le 34). D'où le fait d'avoir fait l'impasse sur ce cas.

pour l'exemple demandé. J'ai encore du travail par ici.
https://www.openstreetmap.org/search?query=lunel#map=15/43.6984/4.1552

Pour le cas de l'impasse non on est bien sur un highway=residential. Car on
est dans un système résidentiel qui plus est sur voie publique dont l'accès
permet la circulation à double sens sans réelle contrainte. J'avoue
volontier qu'il m'est encore difficile de faire des choix entre highway
residentiel et highway service sur des voies privé à fort gabarit.
D'ailleurs il n'y a pas d'obligation à mettre utiliser le couple
service=alley. Ca a été inscrit ainsi pour les groupes de résidences sur la
Page FR et ça diverge du contexte général. Sur la page général alley c'est
pour le chemin secondaire des résidences ou voies étroites en zone
européenne pour les centre de type médiévaux...
C'est pas le sujet. Le principe et de dissocier système track du reste. Qui
plus est sur le système de type chemin il n'y a pas de panneaux d'entrée et
sortie de ville à ma connaissance (à confirmer et ça doit rentrer dans un
cadre légal)
 https://wiki.openstreetmap.org/wiki/FR:Key:service

Pour exemple:
https://www.openstreetmap.org/search?query=lunel#map=19/43.67157/4.12534



Le jeu. 8 août 2019 à 13:49, Stéphane Péneau  a
écrit :

> Le gros problème de toute cette discussion, c'est qu'il n'y a pas
> d'exemple, de lien vers un highway d'Osm.
>
>
> Le 08/08/2019 à 11:53, Jérôme Seigneuret a écrit :
> >
> > Du coup highway unclassified reste sur les occupations non
> > résidentielle et hors système forestier et bocager, en landuse
> > residentiel c'est highway=residentiel qui prime et dans les systèmes
> > ruraux (sauf route principale) ce sont des chemins ou voies donc
> > track. Après c'est le tracktype et son grade qui compte.
> >
> Donc, pour toi ceci devrait être un track ?
>
> https://www.openstreetmap.org/way/112796056
>
>
> > highway=service+service=alley pour le wiki français est un chemin
> > servant à desservir un groupe de résidences.
> >
> Ce n'est pas de cette façon que je lis le wiki.
>
> Exemple, pour toi, ceci serait un service=alley ?
>
> https://www.openstreetmap.org/way/133901363
>
>
> Stf
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-be] Tr : Vhello - New Cycle Nodes Network / Nouveau réseau Points-Noeuds Vélo / Niew Fietsknooppunten

[marc marc]

Hello,

Le 08.08.19 à 14:05, corentin.marec...@hainaut.be a écrit :
> we translated in french the following page: 
> https://wiki.openstreetmap.org/wiki/Cycle_Node_Network_Tagging
> How can I add it for the community ?

clic on "Toutes les langues", and "Français",
save your translation there, including wikicode,
use preview before saving

Regards,
Marc

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

Re: [Talk-se] Lantmäteriets öppna data

[Christian Asker]

Hej. Terrängkartan är lite knepig eftersom själva datat är anpassat för 
att objekt inte ska ligga ovanpå varandra för mycket (så att kartan blir 
för plottrig). Det innebär att en del objekts positioner har justerats. 
Tex vägar kan ligga 10 meter fel jämfört med Trafikverkets data.


Ytor (som skog tex) består dessutom av väldigt stora multipolygoner, som 
är svåra att hantera. När jag försökte att importera Terrängkartan 
upplevde jag att det var mindre jobb att helt enkelt rita ytor för hand 
utifrån flyg-/satellit-foton. Dessutom stämmer inte alltid 
markanvändningen i Terrängkartan med verkligheten; i de områden jag har 
provat har en hel del åkermark blivit skog under de senaste decennierna 
och Terrängkartan verkar inte ha uppdaterats...


I slutändan har jag mest importerat traktorvägar, lite stigar, 
fornlämningar och liknande från Terrängkartan; resten har visat sig inte 
vara mödan värt. Detta är dock bara min personliga åsikt; det kan ju 
hända att någon som är mer GIS-kompetent än jag har andra erfarenhetet.



Jag har skrivit lite om det här i min OSM-dagbok: 
https://www.openstreetmap.org/user/ChristianA/diary/43315


Där kan du även se bilder som förklarar vad jag menar.


Mvh ChristianA



Den 2019-08-08 kl. 13:41, skrev Eva Lindberg:
Tack för svar! Dessa inlägg hade jag inte sett. Har diskussionen 
fortsatt senare?


Som jag skrev nedan tror jag också att NMD är bättre än terrängkartan 
för markklasser. Framförallt för att den är gjord för att klassa mark 
medan det blir lite konstigt med markklasser i vektorformat av orsaker 
som togs upp i tråden som du länkade till. Dessutom är NMD bra för att 
den har fler klasser än de som finns i terrängkartan. Nackdelar med 
NMD är som någon tog upp dels att en klass som tex skog kan ha hål 
eftersom enstaka fläckar blir klassade som något annat och dels 
felklassning som kan bli bättre med manuella metoder vilket ligger 
till grund för tex terrängkartan. Sedan har ju NMD fördelen att den 
kan uppdateras regelbundet medan terrängkartan kan ha fel pga att data 
är föråldrade.


Men det jag är ute efter är framförallt vektorobjekt som vägar, hus 
och vattendrag som finns i terrängkartan. Det finns stora områden i 
Sverige som inte är karterade alls i OSM och där skulle de hjälpa.


MVH /Eva

On 2019-08-08 12:40, Karl-Johan Karlsson wrote:

Terrängkartan har diskuterats lite tidigare. Se:
https://lists.openstreetmap.org/pipermail/talk-se/2019-April/003651.html

Den tors 8 aug. 2019 kl 12:00 skrev Eva Lindberg :


Jag är ny användare här och anledningen att jag är intresserad
av OSM är
att jag vill ha en bra karta för ett visst område i norra Sverige.

Området verkar just nu inte vara karterat överhuvudtaget. Det är
här:
https://www.openstreetmap.org/#map=12/63.5201/17.9881

Jag har lite koll på GIS och kartor och tycker att ett effektivt
sätt
att få in grundläggande kartor för området skulle vara att
importera
Lantmäteriets öppna data, speciellt terrängkartan. Jag förstår
att det
kräver dels att användarna av OSM vill ha in det och dels att man
kollar
kollisioner vid importen så att man inte förstör något som redan
är
karterat. Eftersom Lantmäteriets kartor finns för hela landet
undrar jag
om man skulle kunna ta ett större grepp så att det finns struktur
för
att lägga in kartorna för andra områden om någon vill.

Jag hittar ingen större diskussion om Lantmäteriets öppna data
varken
här, på forumet eller på wikin. Har det diskuterats och vad har i
så
fall kommit fram?

Finns det intresse av att få in information från Lantmäteriets
terrängkarta i OSM?

Är någon här som är mer erfaren när det gäller import av
öppna data från
myndigheter och kan ge råd eller hjälp?

Jag har sett att det finns en diskussion om Nationella
Marktäckedata
från Naturvårdsverket som också är öppna data och det ser ut
som att
arbete pågår för att få in det i OSM. Om terrängkartan ska
läggas in får
den naturligtvis inte krocka med NMD som ofta är bättre än
terrängkartan. Jag undrar också: Har de som håller på med NMD
någon
åsikt om eller plan för Lantmäteriets öppna data?

Tack /Eva Lindberg

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

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


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


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

[OSM-talk-be] Tr : Vhello - New Cycle Nodes Network / Nouveau réseau Points-Noeuds Vélo / Niew Fietsknooppunten

[Corentin . Marechal]

Hey !

We recently created a new cycle nodes Network in the Region of the Heart 
of Hainaut (Mons / La Lovuière).
We would like to import it in openstreetmap / opencyclemap.

Find enclosed the shape files with the data:
- Nodes: 
https://drive.google.com/drive/folders/1kG3Vt4h8KL2yW0Zcsb6peElXYye8WbLG?usp=sharing
- Ways: 
https://drive.google.com/drive/folders/1uF4_nMFXmTuh89BTYbWLtCDhTTTtQ7hs?usp=sharing

Key
Value
Comment
type
network
Denotes that this relation is a collection of all junctions and routes 
making up the network.
network
rcn
Denotes that this is a cycle node network. 'rcn' is the currently 
established tag for a cycle node network in Belgium, The Netherlands and 
Germany.
name
name
Vhello
operator
operator
Fédération du Tourisme de la Province de Hainaut

Tables description: 
https://drive.google.com/file/d/1wVzidkHzwiRawFexkRH2pRvCsncK1PhN/view?usp=sharing

Further more: we translated in french the following page: 
https://wiki.openstreetmap.org/wiki/Cycle_Node_Network_Tagging
How can I add it for the community ? Can you help us to import it ?
=> 
https://drive.google.com/file/d/13wIOBkp4W--U5WhL-56NAwsYqfpUP1ai/view?usp=sharing

Thank you in advance!

Best regards.

Corentin

 

Hainaut Culture Tourisme
 
Corentin Marechal -  Responsable Développement & Pôle numérique
Tél. : +32(0)65/39.75.67   Fax : +32(0)65/33.57.32
 
 
Email : corentin.marec...@hainaut.be
Site web : www.hainaut.be___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-fr] Track -> Chemin rural

[Stéphane Péneau]

Le gros problème de toute cette discussion, c'est qu'il n'y a pas 
d'exemple, de lien vers un highway d'Osm.



Le 08/08/2019 à 11:53, Jérôme Seigneuret a écrit :


Du coup highway unclassified reste sur les occupations non 
résidentielle et hors système forestier et bocager, en landuse 
residentiel c'est highway=residentiel qui prime et dans les systèmes 
ruraux (sauf route principale) ce sont des chemins ou voies donc 
track. Après c'est le tracktype et son grade qui compte.



Donc, pour toi ceci devrait être un track ?

https://www.openstreetmap.org/way/112796056


highway=service+service=alley pour le wiki français est un chemin 
servant à desservir un groupe de résidences.



Ce n'est pas de cette façon que je lis le wiki.

Exemple, pour toi, ceci serait un service=alley ?

https://www.openstreetmap.org/way/133901363


Stf



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

Re: [Talk-se] Lantmäteriets öppna data

[Eva Lindberg]

Tack för svar! Dessa inlägg hade jag inte sett. Har diskussionen 
fortsatt senare?


Som jag skrev nedan tror jag också att NMD är bättre än terrängkartan 
för markklasser. Framförallt för att den är gjord för att klassa mark 
medan det blir lite konstigt med markklasser i vektorformat av orsaker 
som togs upp i tråden som du länkade till. Dessutom är NMD bra för att 
den har fler klasser än de som finns i terrängkartan. Nackdelar med NMD 
är som någon tog upp dels att en klass som tex skog kan ha hål eftersom 
enstaka fläckar blir klassade som något annat och dels felklassning som 
kan bli bättre med manuella metoder vilket ligger till grund för tex 
terrängkartan. Sedan har ju NMD fördelen att den kan uppdateras 
regelbundet medan terrängkartan kan ha fel pga att data är föråldrade.


Men det jag är ute efter är framförallt vektorobjekt som vägar, hus och 
vattendrag som finns i terrängkartan. Det finns stora områden i Sverige 
som inte är karterade alls i OSM och där skulle de hjälpa.


MVH /Eva

On 2019-08-08 12:40, Karl-Johan Karlsson wrote:

Terrängkartan har diskuterats lite tidigare. Se:
https://lists.openstreetmap.org/pipermail/talk-se/2019-April/003651.html

Den tors 8 aug. 2019 kl 12:00 skrev Eva Lindberg :


Jag är ny användare här och anledningen att jag är intresserad
av OSM är
att jag vill ha en bra karta för ett visst område i norra Sverige.

Området verkar just nu inte vara karterat överhuvudtaget. Det är
här:
https://www.openstreetmap.org/#map=12/63.5201/17.9881

Jag har lite koll på GIS och kartor och tycker att ett effektivt
sätt
att få in grundläggande kartor för området skulle vara att
importera
Lantmäteriets öppna data, speciellt terrängkartan. Jag förstår
att det
kräver dels att användarna av OSM vill ha in det och dels att man
kollar
kollisioner vid importen så att man inte förstör något som redan
är
karterat. Eftersom Lantmäteriets kartor finns för hela landet
undrar jag
om man skulle kunna ta ett större grepp så att det finns struktur
för
att lägga in kartorna för andra områden om någon vill.

Jag hittar ingen större diskussion om Lantmäteriets öppna data
varken
här, på forumet eller på wikin. Har det diskuterats och vad har i
så
fall kommit fram?

Finns det intresse av att få in information från Lantmäteriets
terrängkarta i OSM?

Är någon här som är mer erfaren när det gäller import av
öppna data från
myndigheter och kan ge råd eller hjälp?

Jag har sett att det finns en diskussion om Nationella
Marktäckedata
från Naturvårdsverket som också är öppna data och det ser ut
som att
arbete pågår för att få in det i OSM. Om terrängkartan ska
läggas in får
den naturligtvis inte krocka med NMD som ofta är bättre än
terrängkartan. Jag undrar också: Har de som håller på med NMD
någon
åsikt om eller plan för Lantmäteriets öppna data?

Tack /Eva Lindberg

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

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


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

Re: [Talk-de] Änderungen im Wiki: Tag:public transport=platform

[Roland Olbricht]

Hallo Nzara,

da pflichte ich Martin dringend bei. Gut 99% aller Name-Nutzungen an
public_transport=platform in Deutschland sind die Namen der Station.

Ich habe das für die fünf größten Bundesländer ausgezählt:

Land Hst mit Name  Hstname  Steigref
NRW673246630466299 5
Bayern 391263409733991   106
BaWü   256732215922002   157
NDS22372204432038063
Hessen 22967214852147124

Da es eine händische Sichtung der Hstnamen ist, werde ich das auch nicht
aufs ganze Bundesgebiet ausdehnen; der Trend ist eindeutig.

Wer selber bei sich auszählen möchte, kann alle vorkommenden Namen listen:
https://overpass-turbo.eu/s/Lp4
Bitte die Bounding-Box zum Zielort schieben.

Wenn es einen Sonderwunsch gibt, kann man den gerne diskutieren. Aber er
gehört auf keinen Fall in die Tag-Dokumentation; Leser der Dokumentation
könnten das für anerkannt halten. Wenn ein Tag wie hier breite
Verwendung gefunden hat, sollte es auch auf keinen Fall umdefiniert werden.

Ich persönlich halte diesen Sonderwunsch auch nicht für sinnvoll. Ziel
muss es sein, das Arbeiten für den Mapper einfach zu halten, und da ist
es besser, wenn wir für jedes Objekt (Straße, Ladengeschäft,
Bushaltestelle, etc.) beibehalten: Name ist die Bezeichnung, die am
Schild drüber dafür steht.

Viele Grüße,

Roland

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

Re: [Talk-GB] Tintagel bridge

[Gregory Marler]

I think the most active Cornwall mappers are further South (around Falmouth
and The Lizard). Some of them are focused are lot on foreign humanitarian
mapping but also do some mapping locally. There are also some mappers who
travel to Cornwall regularly but don't live there.

On Thu, 8 Aug 2019 at 12:14, ael  wrote:

> On Thu, Aug 08, 2019 at 07:23:00AM +0100, Jez Nicholson wrote:
> > Has anyone prepared Tintagel bridge? Opening on Sunday.
>
> As far as I can see, we don't have any local mappers. Perhaps I may
> have missed some.
>
> I am in Cornwall just now, and *might* be able to do a proper survey
> but it is fair distance and it probably won't happen. Anyone in that
> area?
>
> ael
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>


-- 
Gregory Marler
No More Grapes
07939 689 691
i...@nomoregrapes.com
http://www.nomoregrapes.com
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-be] Ways with identical coordinates on top of each other

[Marc Gemis]

I assume OSM always has been a 2.5D map. I'm thinking about tunnels
and bridges. To properly map them, we always needed the level tag. So
any data consumer that creates a road network from OSM will need to
have knowledge about the level tag.
Of course, the example that you mention, of indoor mapping with
multiple levels, is not properly solved by carto-css (the default
rendering on osm.org). The problem will also occur for POIs on
different floors. People have been experimenting with other
representations to make this type of data understandable.
I guess more and more 3D features will be added to the data, the
question is how fast will the data consumers come up with
representations that are easy to understand.

regards

m.

On Thu, Aug 8, 2019 at 12:22 PM Florian Goetghebeur
 wrote:
>
> Hello,
>
> I recently came across a parking building with multiple floors in OSM, in 
> which ways are tagged with 'level' and 'layer' tags. It struck me that there 
> are ways that have the very same geometry on different levels (see links 
> below). As a result, the map has four arrows (one for each level), indicating 
> the oneway direction, with only little space in between. It looks strange to 
> me. But having nodes and ways stacked on top of each other might have other 
> unwanted consequences, e.g. when you try to process the OSM data to get a 
> road network for routing and you do not take the level and layer tags into 
> account.
>
> So I am now wondering about the community's vision about this 2D vs 3D issue. 
> Can OSM still be seen as a 2D map? In what way is OSM evolving regarding this 
> topic? We now have this strange blend between a 2D visualization and a few 3D 
> tags that can cause issues. The notes and comments for the nodes below show 
> that there have been problems already.
>
> Thanks for sharing your insights!
>
> Four nodes at the same location:
> https://www.openstreetmap.org/node/4359171125
> https://www.openstreetmap.org/node/4359171126
> https://www.openstreetmap.org/node/4359171127
> https://www.openstreetmap.org/node/4359171128
> Two ways with the exact same coordinates:
> https://www.openstreetmap.org/way/438182278
> https://www.openstreetmap.org/way/438182283
>
> Kind regards,
> Florian
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [Talk-GB] Tintagel bridge

[ael]

On Thu, Aug 08, 2019 at 07:23:00AM +0100, Jez Nicholson wrote:
> Has anyone prepared Tintagel bridge? Opening on Sunday.

As far as I can see, we don't have any local mappers. Perhaps I may
have missed some.

I am in Cornwall just now, and *might* be able to do a proper survey
but it is fair distance and it probably won't happen. Anyone in that
area?

ael


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

Re: [Talk-se] Lantmäteriets öppna data

[Karl-Johan Karlsson]

Terrängkartan har diskuterats lite tidigare. Se:
https://lists.openstreetmap.org/pipermail/talk-se/2019-April/003651.html

Den tors 8 aug. 2019 kl 12:00 skrev Eva Lindberg :

> Jag är ny användare här och anledningen att jag är intresserad av OSM är
> att jag vill ha en bra karta för ett visst område i norra Sverige.
> Området verkar just nu inte vara karterat överhuvudtaget. Det är här:
> https://www.openstreetmap.org/#map=12/63.5201/17.9881
>
> Jag har lite koll på GIS och kartor och tycker att ett effektivt sätt
> att få in grundläggande kartor för området skulle vara att importera
> Lantmäteriets öppna data, speciellt terrängkartan. Jag förstår att det
> kräver dels att användarna av OSM vill ha in det och dels att man kollar
> kollisioner vid importen så att man inte förstör något som redan är
> karterat. Eftersom Lantmäteriets kartor finns för hela landet undrar jag
> om man skulle kunna ta ett större grepp så att det finns struktur för
> att lägga in kartorna för andra områden om någon vill.
>
> Jag hittar ingen större diskussion om Lantmäteriets öppna data varken
> här, på forumet eller på wikin. Har det diskuterats och vad har i så
> fall kommit fram?
>
> Finns det intresse av att få in information från Lantmäteriets
> terrängkarta i OSM?
>
> Är någon här som är mer erfaren när det gäller import av öppna data från
> myndigheter och kan ge råd eller hjälp?
>
> Jag har sett att det finns en diskussion om Nationella Marktäckedata
> från Naturvårdsverket som också är öppna data och det ser ut som att
> arbete pågår för att få in det i OSM. Om terrängkartan ska läggas in får
> den naturligtvis inte krocka med NMD som ofta är bättre än
> terrängkartan. Jag undrar också: Har de som håller på med NMD någon
> åsikt om eller plan för Lantmäteriets öppna data?
>
> Tack /Eva Lindberg
>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

[OSM-talk-nl] Hyperlink in window van een pointer werkt niet

[Jan Pieter de Groot]

Inmiddels heb ik het probleem zelf kunnen oplossen door de informatie 
van de pointer niet via Tooltip maar via Popup te tonen. Nadeel is wel 
dat de pointer nu moet worden aangeklikt.


Jan Pieter de Groot

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

Re: [Talk-it] Quesito stabile nuovo da mappare

[Federico Cortese]

On Wed, Aug 7, 2019 at 11:20 PM totera  wrote:
>
> Nelle delibere comunali poi quando si fa riferimento a un edificio si parla
> di "edificio sito al civico 17 di via Tal de' Tali" anziché di "edificio a
> cui si accede dal civico 17 di via Tal de' Tali".

Di solito si parla di edificio con accesso da via, num, ma anche
se fosse non significa che l'edificio non abbia altri accessi con
numeri diversi.

> Le unità immobiliari possono avere più accessi ma al catasto saranno censite
> con un solo indirizzo.

Nel Docfa (software ministeriale per gli accatastamenti) per ogni
unità immobiliare c'è il campo "Ubicazione" dove si inserisce la via e
diversi campi "Numeri Civici" (scritto proprio così al plurale) per
poter inserire quanti civici si vuole.

> Negli stessi SIT sui siti di molti comuni i civici sono posizionati
> sull'edificio e non sull'accesso dall'area di circolazione proprio per
> permettere di identificare quale sia il civico dell'edificio o viceversa a
> quale edificio il civico faccia riferimento. Tutto sbagliato anche lì?
>

Mai visto, ma se è così è certamente sbagliato. D'altra parte su un
edificio con più civici cosa mettono?

>
> Capisco il tuo richiamo alla normativa ISTAT, ma vorrei farti notare che
> essa è largamente disattesa dagli stessi comuni, e nella realtà si
> incontrano spesso queste situazioni:
> - due, tre o un numero anche maggiore di civici messi tutti insieme su un
> accesso condiviso da più edifici
> - civici posizionati sull'edificio in un punto non raggiungibile dai non
> residenti e cancello sull'area di circolazione con citofoni e cassette della
> posta ma senza civico
> - i famigerati snc (che immagino siano tutti dovuti a inadempienza dei
> comuni)

Queste difformità sono dovute a situazioni precedenti alla normativa
ISTAT che è abbastanza recente ed è stata scritta proprio per
risolvere questi problemi e creare uniformità.
Inoltre gli uffici toponomastica dei comuni stanno progressivamente
ponendo rimedio, adeguandosi a quanto richiesto da ISTAT.

> Il validatore e gli strumenti simili però accettano l'indirizzo sulle aree.
> Se tu ritieni che l'indirizzo vada su un punto devi rinunciare a pretendere
> l'unicità.

Chiaramente lo accettano perchè fuori dall'Italia possono esserci
regole diverse (ad esempio civico assegnato al lotto o al fabbricato e
non all'accesso).
Se in Italia ormai sono tutti d'accordo - ISTAT, Agenzia delle Entrate
(Catasto), Comuni - non vedo perchè noi dovremmo invece assegnare i
civici agli edifici.

Ciao,
Federico

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

[OSM-talk-be] Ways with identical coordinates on top of each other

[Florian Goetghebeur]

Hello,

I recently came across a parking building with multiple floors in OSM, in which 
ways are tagged with 'level' and 'layer' tags. It struck me that there are ways 
that have the very same geometry on different levels (see links below). As a 
result, the map has four arrows (one for each level), indicating the oneway 
direction, with only little space in between. It looks strange to me. But 
having nodes and ways stacked on top of each other might have other unwanted 
consequences, e.g. when you try to process the OSM data to get a road network 
for routing and you do not take the level and layer tags into account.

So I am now wondering about the community's vision about this 2D vs 3D issue. 
Can OSM still be seen as a 2D map? In what way is OSM evolving regarding this 
topic? We now have this strange blend between a 2D visualization and a few 3D 
tags that can cause issues. The notes and comments for the nodes below show 
that there have been problems already.

Thanks for sharing your insights!

Four nodes at the same location:
https://www.openstreetmap.org/node/4359171125
https://www.openstreetmap.org/node/4359171126
https://www.openstreetmap.org/node/4359171127
https://www.openstreetmap.org/node/4359171128
Two ways with the exact same coordinates:
https://www.openstreetmap.org/way/438182278
https://www.openstreetmap.org/way/438182283

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

Re: [OSM-talk] Survey on global and local communities in OpenStreetMap

[Christoph Hormann]

On Thursday 08 August 2019, Frederik Ramm wrote:
> > By speaking directly and publishing my responses i risk being
> > challenged and criticized personally.  While i don't mind this
> > there are definitely a lot of people who don't want or can't do
> > this.  And many of them probably would not mind their answers being
> > published anonymously.
>
> So essentially all you want is a fourth option in the initial
> "Permission" question that is called
>
> "Publicly, anonymized" ?

Yes, the logical choices that can be offered in a survey like this are 
IMO:

* only allow publication of the statistically aggregated results (what 
you usually have in an analysis of surveys, like percentages).  For 
free form answers this requires subjective interpretation.

* allow anonymized publication of individual answers.  The anonymization 
happens by disconnecting the individual answers from each other so 
answers allowing the identification of a participants (like OSM user 
name) cannot be connected to other answers.  In addition identifying 
information could also be redacted from free form answers for 
publication.

* allow full publication of the raw data (which is not really necessary 
to provide as an option since this participants can easily do on their 
own).

* optionally to either of these allow non-public dissemination of raw 
data to certain parties.

-- 
Christoph Hormann
http://www.imagico.de/

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

[Talk-se] Lantmäteriets öppna data

[Eva Lindberg]

Jag är ny användare här och anledningen att jag är intresserad av OSM är 
att jag vill ha en bra karta för ett visst område i norra Sverige. 
Området verkar just nu inte vara karterat överhuvudtaget. Det är här:

https://www.openstreetmap.org/#map=12/63.5201/17.9881

Jag har lite koll på GIS och kartor och tycker att ett effektivt sätt 
att få in grundläggande kartor för området skulle vara att importera 
Lantmäteriets öppna data, speciellt terrängkartan. Jag förstår att det 
kräver dels att användarna av OSM vill ha in det och dels att man kollar 
kollisioner vid importen så att man inte förstör något som redan är 
karterat. Eftersom Lantmäteriets kartor finns för hela landet undrar jag 
om man skulle kunna ta ett större grepp så att det finns struktur för 
att lägga in kartorna för andra områden om någon vill.


Jag hittar ingen större diskussion om Lantmäteriets öppna data varken 
här, på forumet eller på wikin. Har det diskuterats och vad har i så 
fall kommit fram?


Finns det intresse av att få in information från Lantmäteriets 
terrängkarta i OSM?


Är någon här som är mer erfaren när det gäller import av öppna data från 
myndigheter och kan ge råd eller hjälp?


Jag har sett att det finns en diskussion om Nationella Marktäckedata 
från Naturvårdsverket som också är öppna data och det ser ut som att 
arbete pågår för att få in det i OSM. Om terrängkartan ska läggas in får 
den naturligtvis inte krocka med NMD som ofta är bättre än 
terrängkartan. Jag undrar också: Har de som håller på med NMD någon 
åsikt om eller plan för Lantmäteriets öppna data?


Tack /Eva Lindberg

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

Re: [OSM-talk] Survey on global and local communities in OpenStreetMap

[Frederik Ramm]

Hi,

On 08.08.19 00:52, Christoph Hormann wrote:
> By speaking directly and publishing my responses i risk being challenged 
> and criticized personally.  While i don't mind this there are 
> definitely a lot of people who don't want or can't do this.  And many 
> of them probably would not mind their answers being published 
> anonymously.

So essentially all you want is a fourth option in the initial
"Permission" question that is called

"Publicly, anonymized" ?

Bye
Frederik

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

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

Re: [OSM-talk-fr] Track -> Chemin rural

[Jérôme Seigneuret]

@Jérome Amagat je rejoins bien ton point de vu.


Un chemin est un chemin! pourquoi mettre ça en highway=unclassified?
Le chemin est d'importance local. Il sert à desservir une ferme des champs
des bois. A relier les écarts vers un route de plus grand importances.

Highway=track n'est pas assimilé seulement à une piste.
Encore une fois on tombe dans le problème de définition clair...

Le fait qu'un chemin soit goudronnée ne change en rien ça définition. on a
une notion de surface. On peut très bien avec un
highway=residential+surface=paved

Faut pas oublier que dans certains villages on n'a quasiment que des
lieudits donc pas de rue (peu de highway=residential) et rarement des noms
de voies car l'adressage n'oblige à mettre des noms qu'à partir d'une
certaines tailles de la zone habitées et les numéros d'adresse c'est le
même délire.
D'où sur le cadastre le nom de voie de A à B. Celles-ci ont été abrégé par
défaut sur OSM ce qui n'a pas de réalité en fait. Bref noname=yes n'est
quasiment jamais mis
Au réel on ne devrait avoir qu'une référence et les lieudits bien placé.

La notion de route a un contexte historique qui permet de relier un point A
à un point B d'une importance particulière qui fait que le chemin est nommé
route et non chemin.
D'où les notes sur la cadastre et autre. exemple Route d'Avignon etc qui
portent des références nationale et départementale car considérés
d'importante (et cela depuis la révolution XVIII) C'est route on donc été
aménager pour le trafic de l'époque ce qui fait de dans certains
centre-ville on peut avoir des choses un peu compliqué. Heureusement le
réseau évolue et d'autres départementales ont été créée pour éviter les
problèmes de gabarit et d'engorgement.

Vu que l'on tient tant à calquer au contexte réglementaire, vous pouvez
relire les textes qui font que les chemins sont des chemin et pas autre
chose. (exemple des chemins de halage, des chemin vicinaux, des chemins
agricoles, forestiers, rural, chemin d'exploitation)

Le chemin d'exploitation est privé par défaut d'ailleurs quant au chemin
communal il fait partie du domaine public.

Les chemins desservant une habitation dans un système de voies de type
track doivent rester du même type au niveau de l'habitation. C'est le cas
des fermes si elles sont isolés du système résidentiel. En soit c'est quand
même bien en lien avec les types de landuse...
Cela fait partie des bonne pratique de modélisation.

Du coup highway unclassified reste sur les occupations non résidentielle et
hors système forestier et bocager, en landuse residentiel c'est
highway=residentiel qui prime et dans les systèmes ruraux (sauf route
principale) ce sont des chemins ou voies donc track. Après c'est le
tracktype et son grade qui compte.

Ces chemins ne sont d'ailleurs pas aménager pour circuler à 80 avec deux
voitures en principe sans poser le roue dans le fossé ou permettre le
croisement d'un PL et d'une voiture. (Le risque de perdre son rétro et
quand même pas mal)

Comme les chemins sont de faible importance le but n'est pas d'en faire un
entretien drastique et c'est une réduction de coût pour les communes (et
nos impôts locaux vous remercies)
Le chemins ne sont pas privilégiés pour le routing. Un highway=unclassified
aura quand à lui le même comportement qu'un highway=residentiel

En terme d'importance; je mettrai le highway=track au même niveau qu'un
highway=service+service=alley l'un s'opposant à l'autre en terme de système
de réseaux ruraux et urbain

highway=service+service=alley pour le wiki français est un chemin servant à
desservir un groupe de résidences.

Et pour les gens qui regarde à coté de nos frontières, les types et les
modes de classifications diverges des autres pays car la définition des
valeurs de ces clés sont propres à chacun.
Le fait de trouver ou non des primary, secondary ou tertiary, en modifier
l'importance devrait être lié et dirigé uniquement par les choix fait pour
juguler le traffic. (et le routing qui en découle). Si tout le monde veut
prendre le plus cours chemin et prendre des routes non aménager pour ce
type de traffic n'en fera pas une route d'une plus grande importance mais
juste une route qui saturera plus vite et sera plus dangereuse.
A cet effet les aménageurs décident de baisser la vitesse des routes à
70km/h dans ce cas.

L'importance des voies est dicté par les opérateurs du réseaux pour définir
comment diriger le flux routier de la meilleure manière possible. Cette
notion n'est ni en lien avec le plus cours chemin ni en lien avec les
habitudes des locaux pour gagner 5 minutes.
D'ailleurs dans le cas d'un contournement c'est le contournement qui
récupère l'importance. Si celle-ci concerne une départementale, dans ce cas
l'ancienne perd en importance. Par ailleurs elle peut être concédé à la
commune pour la gestion et donc perdre sa référence de route départementale.
Toute route départementale doit avoir à minima un niveau d'importance
tertiary.

Jérôme


Le mer. 7 août 2019 à 11:10, Jean-Claude 

Re: [OSM-talk] Survey on global and local communities in OpenStreetMap

[Christoph Hormann]

On Thursday 08 August 2019, Mikel Maron wrote:
> > My main concern is rather that there are a lot of free form
> > questions yet there is no option for the participants to allow
> > publication of the individual free form answers in anonymized
> > form. 
>
> Select “publicly aggregated and anonymously” as answer to the first
> question and the free form answers will be published.

Aggregated means exactly the opposite.

-- 
Christoph Hormann
http://www.imagico.de/

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

[talk-au] Considering future Open Geospatial conferences in Oceania

[John Bryant]

Hi all, please see the following message below:

“What should we do about upcoming conferences for Free and Open Source
Software for Geospatial (FOSS4G) and State of the Map (SotM) within our
Oceania region?”

Image by @mapmakerdavid


We didn’t have an answer to this question at the last OSGeo Oceania board
meeting. At the moment, no one is volunteering to chair. No one is backing
a city with commitment, and that is a problem we hope to solve.

Pertinent is that the international FOSS4G will be held somewhere outside
of Europe or North America in 2021 and a call for a two-page Expression Of
Interest is coming in September
. We have a very
compelling
case 
for bringing the international community to our region, if we try.

Are you keen to see FOSS4G & SotM continue in our region? Do you have ideas
about where and how? Would you like to help make it happen? Are you
interested in mentoring or being mentored by a bunch of committed
volunteers who have worked on prior FOSS4G events? If so, why don’t you
talk to us? Come join our email list
 and introduce
yourself. We particularly want to hear ideas about what we should do about
FOSS4G in the next two years.

Some history:

   -

   2009: FOSS4G-International in Sydney. During the global financial
   crisis, we had lower attendance than expected, but managed to stay
   profitable when similar conferences were losing money.
   -

   2018: FOSS4G SotM Oceania in Melbourne. Exceeded expectations for size,
   sponsorship, activities, and engagement.
   -

   2019: FOSS4G SotM Oceania Wellington :
   Has already exceeded sponsorship targets and sold out early bird tickets
   within a week.
   -

   *2020: FOSS4G SotM Oceania: Where?*
   -

   *2021: FOSS4G-International Should we bid for it?*


We are looking forward to hearing from you,

John Bryant (OSGeo Oceania president) and Cameron Shorter (scribe).
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] [FOSS4G-Oceania] GHG mitigation and FOSS4G SotM Oceania

[Dion Moult]

I don't want to discourage from the local woodlands initiative, I think it's 
absolutely great to do.

I did want to being up the Cool Earth charity[1], which has been through lots 
of independent evaluation as to their effectiveness. Independent analysis 
suggests that their rate is at 0.71 USD per tCO2eq[2], but on their website it 
seems to be higher, approximately 2AUD per tCO2eq.

If you wanted to consider more than carbon... I have done some really ballpark 
explorations here:

https://thinkmoult.com/effective-altruism-living-net-positive-life.html

Great initiative!

1. https://www.coolearth.org/
2. https://www.givingwhatwecan.org/report/cool-earth/#3-overall-evaluation

Sent from ProtonMail mobile

 Original Message 
On 8 Aug. 2019, 5:47 pm, John Bryant wrote:

> Great work Adam! I agree this looks like a worthwhile program.
>
> On Thu, 8 Aug 2019 at 09:45, Edoardo Neerhut  wrote:
>
>> Fantastic work on this Adam. Parks Victoria would be a wonderful 
>> organisation to fund offset with. Much better than a Cayman Island 
>> registered organisation with plantations in the Amazon. Hopefully the costs 
>> of this approach are within the real of possibility for us.
>>
>> On Thu, 8 Aug 2019 at 15:26, adam steer  wrote:
>>
>>> hey folks
>>>
>>> waking this conversation up again - there’s some interest from Parks 
>>> Victoria around applying funding from a GHG offset scheme to restore yellow 
>>> box woodland - which is direct, local and observable.
>>>
>>> I started making some calculations here: 
>>> https://docs.google.com/spreadsheets/d/1DGcpUCO6pHhKutoCh8qh1FcIrnXjyYQ_kOEIf5nCnGw/edit?usp=sharing
>>>
>>> …using the ICAO flight emissions calculator. So far we’re up to about 48t 
>>> CO2 based on my assumptions around who comes from where - and no additions 
>>> from south pacific islands yet. If you have any input on those numbers 
>>> please add comments.
>>>
>>> Next step is to work more on how much money is appropriate for a programme 
>>> to sequester 48t of CO2 based on existing offset programmes. Then, have a 
>>> chat with Parks Victoria around how far that amount goes.
>>>
>>> I’ll add those estimates in the same sheet.
>>>
>>> Regards
>>>
>>> Adam
>>>
>>> ___
>>> FOSS4G-Oceania mailing list
>>> foss4g-ocea...@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/foss4g-oceania
>>
>> ___
>> FOSS4G-Oceania mailing list
>> foss4g-ocea...@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/foss4g-oceania___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-de] Frage zum tagging Rettungsbaken

[Markus]

Hallo Michael,

> In OpenSeaMap werden sie korrekt angezeigt... :-/

:-)

Richtig eingetragen werden die Rettungplattformen (seemännisch "Bake")
ab z=14 angezeigt, ab z=15 mit amtlichem Namen [1]

Wattwandern wird nur mit Führer empfohlen.
Auch OpenSeaMap ist nur eine Orientierungshilfe.
(denn zu Ebbe und Flut machen wir keine Aussage)

>>> Bei unserem Urlaub auf Jersey habe ich die
>>> Koordinaten eingemessen: N 49°09.821 W002°01.104

Einfach die richtigen tags kopieren 
in JOSM einen Punkt setzen und die tags mit  einfügen
und passend korrigieren (Farbe, Material, Name, etc.)

>>> seamark:beacon_special_purpose:colour = black
>>> seamark:conspicuity = conspicuous
>>> seamark:construction = metal
>>> seamark:name = Ret. 1
>>> seamark:reflectivity = conspicuous
>>> seamrak:souce = BfS 53/19 WSA Cuxhaven
>>> seamark:status = permanent
>>> seamarkt:type = beacon_special_purpose

Wenige Minuten später ist die Plattform dann auf OpenSeaMap sichtbar.

Mit herzlichem Gruss,
Markus

[1] Rettungsbake "Ret 3":
http://map.openseamap.org/?zoom=14=53.90496=8.61769=53.91166=8.62486=%3Cb%3ERettungsbake%20%3C%2Fb%3E%0ARet%203=BFTFFFTFFTT0TF

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

Re: [OSM-talk-fr] Manque d'attribution : je suis estomaquée

[Cyrille37 OSM]

Salut,

Mais qui donc est dans une bulle ? Attention, être dans ou hors d"une 
bulle ne donne pas raison.


Je rejoins @marc_marc sur le fait qu'il faut être courtois et 
compréhensif. Il ne faut pas développer une méthode pour les "coupables" 
que l'on appliquerait aux "innocents" qui sont souvent la majorité. 
Sorti de certains cercles (ou bulles) il y a bien peu de gens, même 
professionnels, sensibilisés aux règles de "partage / propriété" comme 
nous pouvons l'être ; nn peut le déplorer mais pas être en colère.


La bienveillance est certainement la meilleur amie de l'apprentissage :-)

Cyrille37.

Le 07/08/2019 à 23:52, François Lacombe a écrit :

Bonsoir Marc,

Le mar. 6 août 2019 à 20:42, marc marc > a écrit :


je vous trouve très dur, inutilement dur... sortez de votre bulle !


Dans la forme pour ce coup, certainement.
Quoi que je n'en ai pas rajouté vu que beaucoup de contacts sont 
partis pour ce cas-ci.


Sur le fond en revanche, je pense que nos signalements pressants sont 
légitimes.
Cela fait des années que je passe beaucoup de temps à vérifier 
l'utilisation du contenu que je publie en CC (pas pour osm donc). 
Effectivement peu de monde ne respecte.
J'ai du envoyer des centaines de mails, à des acteurs publics comme 
privés qui réutilisent des photos sans respecter les conditions 
(certains n'ont jamais donné suite ni pris de mesures, tout va bien)


Avoir des acteurs qui ont encore cette approche binaire gratuit/payant 
après tout le remue-ménage autour des directives copyright en tout 
genre, du domaine publique et autre, c'est un peu gros (ou alors c'est 
qu'on en a pas assez parlé).
C'est un autre sujet, mais je pense que ce serait aussi à eux de 
sortir de leur bulle pour que tout le monde se rencontre.
Les efforts ne peuvent pas toujours venir de ceux qui font, devant en 
plus être indulgent avec ceux qui profitent.


François

___
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-au] [FOSS4G-Oceania] GHG mitigation and FOSS4G SotM Oceania

[John Bryant]

Great work Adam! I agree this looks like a worthwhile program.

On Thu, 8 Aug 2019 at 09:45, Edoardo Neerhut  wrote:

> Fantastic work on this Adam. Parks Victoria would be a wonderful
> organisation to fund offset with. Much better than a Cayman Island
> registered organisation with plantations in the Amazon. Hopefully the costs
> of this approach are within the real of possibility for us.
>
> On Thu, 8 Aug 2019 at 15:26, adam steer  wrote:
>
>> hey folks
>>
>> waking this conversation up again - there’s some interest from Parks
>> Victoria around applying funding from a GHG offset scheme to restore yellow
>> box woodland - which is direct, local and observable.
>>
>> I started making some calculations here:
>> https://docs.google.com/spreadsheets/d/1DGcpUCO6pHhKutoCh8qh1FcIrnXjyYQ_kOEIf5nCnGw/edit?usp=sharing
>>
>> …using the ICAO flight emissions calculator. So far we’re up to about 48t
>> CO2 based on my assumptions around who comes from where - and no additions
>> from south pacific islands yet. If you have any input on those numbers
>> please add comments.
>>
>> Next step is to work more on how much money is appropriate for a
>> programme to sequester 48t of CO2 based on existing offset programmes.
>> Then, have a chat with Parks Victoria around how far that amount goes.
>>
>> I’ll add those estimates in the same sheet.
>>
>> Regards
>>
>> Adam
>>
>>
>> ___
>> FOSS4G-Oceania mailing list
>> foss4g-ocea...@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/foss4g-oceania
>>
> ___
> FOSS4G-Oceania mailing list
> foss4g-ocea...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/foss4g-oceania
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-ja] JA: Available Dataの改定提案の議論について

[Talk-ja 経由]

こんにちは、奈良の石川です。議論の整理、ありがとうございます。

On Sunday, August 4, 2019, 7:19:39 AM GMT+9, 石野貴之  wrote: 
>これを踏まえると、当初の村本さんの提案
>https://lists.openstreetmap.org/pipermail/talk-ja/2019-June/010597.html
>のうち、
>> ■現状
>> ・判定：◎
>> ・用例：ウェブサイト上の店名、住所、電話番号など
>> ・判定の理由：事実情報
>については現状を維持し(ただし、公式サイト上の一次情報に限ることを明記する)、WikipediaやWikidataについてはデータベース権にも
>触れた上で判定:×とするのが妥当なところだと考えられますが、皆様のご意見はいかがでしょうか。


基本的にそれでよいのではないかと思います。ただ、以下の2点が気になります。

(1) 
「公式サイト上」の情報に限ることは良いと思いますが、「一次情報」に限る必要性を私は感じません。以前も書きましたが、例えば地番表記に於いては法務局に存在する情報こそが一次情報であり、当該地物の所有者・管理者がいくら公式に地番表記の住所を発表してもそれは二次以降の情報に過ぎない、というのが私の立場です。公式に発信されている情報であれば、何次情報であろうと当該地物の所有者・管理者が責任をもって発信しているでしょうから、「一次情報」に限る必要はないと考えます。(私の解釈が絶対に正しいという主張ではなく、そういう解釈をする人も正しく線引きできる表現が望ましい、という主張です。)

(2) 今回の議論に直接含まれてはいないのですが、そもそも「用例」という語がまずいと思います。英語版では「data」となっており、data 
という語には資料や出典という意味合いが含まれますが、日本語の「用例」という語には資料や出典と言う意味合いが含まれません。そのため、「用例」表記のままですと、「Wikipedia
 に掲載されているからこの情報は削除せよ」などと言い出す人が出てくると思います (本来は「Wikipedia 
しか出典がない情報は削除せよ」であるべきです)。以前、これと同様の事例が、個人住宅の表札に関して主張されたこともあります。「JA:Available 
Data」の文章は、複数の解釈の余地がないように正しく記述されることが望ましいと思います。

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

Re: [Talk-de] Änderungen im Wiki: Tag:public transport=platform

[Martin Scholtes]

Hallo Nzara,

deine Ansichten teile ich nicht.

Für mich gehört sowohl an pt=platform als auch an pt=stop_position der
key name!

Eine Ableitung des Namens aus einer stop_area-Relation kann man derzeit
nicht leisten, da vieler Orts solch eine Relation nicht gibt.
Ich sehe viele Mapper die leider pauschal versuchen PTv1 Haltestellen in
PTv2 Haltestellen umzutaggen/erweitern und vergessen zu 99% die
stop_area-Relation.

Am 08.08.2019 um 06:17 schrieb Nzara:
> Wir mappen die Welt, wie sie ist - nicht wie wir sie gerne haben möchten.
Ja da geb ich dir recht und was steht an einer Bushaltestelle: Genau ein
Schild mit der Aufschrift des Namen der Haltestelle. Diese gilt für
pt=platform und pt=stop_position.
> Am 07.08.2019 um 20:18 schrieb KvMP via Talk-de:
>> Wie ist hier die Haltung zu dieser ??nderungen und wird eine
>> Revertierung dieser unterst??tzt?
>> In der OSM-Telegram-Gruppe hatte ich mich mal erkundigt und dort
>> stie?? diese ??nderung auf Ablehnung.
Im Forum wurde es bereits geschrieben, abwarten auf die Rückmeldung des
User, der den Eintrag geändert hat, ansonsten muss die Änderung
zurückgesetzt werden.

-- 
Mit freundlichen Grüßen


Martin Scholtes


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

Re: [Talk-de] Frage zum tagging Rettungsbaken

[Martin Scholtes]

Guten Morgen Michael,

Am 08.08.2019 um 08:02 schrieb Droelfzehn (Michael):
> Wieder daheim bemerke ich, daß der Turm schon eingetragen ist! Für die
> Neugierigen: N 49°09.821 W002°01.104
>
> Dort sind "nur" 3 Tags eingetragen:
> man_made = tower
> name = Refuge Tower
> tower:type = observation
>
> Dem tagging kann ich so nicht zustimmen aber das ist eine andere
> Geschichte.
Grundsätzlich ist der Hauptkey man_made ja richtig gesetzt.
>
> Daraufhin habe ich mir die Rettungsbaken vor Cuxhaven mal in JOSM
> angeschaut, die auf der Karte ebenfalls nicht angezeigt werden...
> Als Beispiel nehme hier mal die Rettungsbake 1 bei N53°54.395
> E008°40.068, die wie folgt getaggt ist:
>
> emergeny = marine_refuge
> seamark:beacon_special_purpose:colour = black
> seamark:conspicuity = conspicuous
> seamark:construction = metal
> seamark:name = Ret. 1
> seamark:reflectivity = conspicuous
> seamrak:souce = BfS 53/19 WSA Cuxhaven
> seamark:status = permanent
> seamarkt:type = beacon_special_purpose
Das kommt vermutlich dadurch zustande das an dieser Node ein
OpenSeaMapper aktiv war.
> Lange Rede, kurzer Sinn: Ich finde es Sinnvoll, die
> Rettungsbaken/Rettungstürme ebenfalls mit dem tag "amenity = shelter" zu
> ergänzen, wobei ich den Zusatz "shelter_type = emergency" als ergänzende
> Information nicht ausschließen möchte, 

Das halt ich hier definitiv dann für falsch. Ein shelter ist für mich
ein Unterstand und keine Rettungsplatform über Meereshöhe. Der Tag
man_made=tower ist da schon richtig angepracht. Der Tag emergency =
marine_refuge gibt es leider nur 11 Mal in der DB, was zeigt, das dieser
nicht dokumentiert ist im Wiki.

> damit diese auf den Karten
> dargestellt werden (können). - Das kann Leben retten.
>
Diese Aussage ist für mich ganz klar  das Argument "mappen für den
Renderer".


-- 
Mit freundlichen Grüßen


Martin Scholtes


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

Re: [talk-au] [FOSS4G-Oceania] GHG mitigation and FOSS4G SotM Oceania

[Edoardo Neerhut]

Fantastic work on this Adam. Parks Victoria would be a wonderful
organisation to fund offset with. Much better than a Cayman Island
registered organisation with plantations in the Amazon. Hopefully the costs
of this approach are within the real of possibility for us.

On Thu, 8 Aug 2019 at 15:26, adam steer  wrote:

> hey folks
>
> waking this conversation up again - there’s some interest from Parks
> Victoria around applying funding from a GHG offset scheme to restore yellow
> box woodland - which is direct, local and observable.
>
> I started making some calculations here:
> https://docs.google.com/spreadsheets/d/1DGcpUCO6pHhKutoCh8qh1FcIrnXjyYQ_kOEIf5nCnGw/edit?usp=sharing
>
> …using the ICAO flight emissions calculator. So far we’re up to about 48t
> CO2 based on my assumptions around who comes from where - and no additions
> from south pacific islands yet. If you have any input on those numbers
> please add comments.
>
> Next step is to work more on how much money is appropriate for a programme
> to sequester 48t of CO2 based on existing offset programmes. Then, have a
> chat with Parks Victoria around how far that amount goes.
>
> I’ll add those estimates in the same sheet.
>
> Regards
>
> Adam
>
>
> ___
> FOSS4G-Oceania mailing list
> foss4g-ocea...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/foss4g-oceania
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-de] Frage zum tagging Rettungsbaken

[Droelfzehn (Michael)]

Hallo Markus!

OpenSeaMap nutze ich eigentlich nie, weshalb OSM für mich immer
OpenStreetMap ist. *rotwerd*
In OpenSeaMap werden sie korrekt angezeigt... :-/

OpenSeaMap:
CUX:
http://map.openseamap.org/?zoom=15=53.90650=8.64157=BFTFFFTFFTF0FF

Openstreetmap:
https://www.openstreetmap.org/search?query=Cuxhaven#map=15/53.9084/8.6486
(Muß dann ggf. noch etwas gezoomt werden.)

Das die Rettungsbaken in OpenSeamaps angezeigt werden ist aufgrund von
"seamark" logisch. - Das die Straßenrenderer dieses Tag nicht
berücksichtigen auch...
Vielleicht sollte man hier zweigleisig fahren?

Liebe Grüße
Michael


Am 08.08.2019 um 08:22 schrieb Markus Bärlocher:

Hallo Michael,

hast Du mir bitte mal einen Link zu den betreffenden Objekten?
In OpenSeeaMap: http://wiki.openseamap.org/wiki/De:Marker_in_URL

Danke, Markus



Am 08.08.2019 um 08:02 schrieb Droelfzehn (Michael):

Hallo zusammen!

Von mir lest Ihr kaum, weil ich meist nicht qualifiziert genug bin an
der Diskussion teilzunehmen aber ich lese hier regelmäßig mit und
versuche auch das eine oder andere umzusetzen, wenn es micht betrifft. ;-)

Nun habe ich aber etwas, bei dem ich gerne Eure Meinung hätte.

Ich nutze die OSM Karten oft und gerne für's Geocachen, weshalb ich OSM
(meistens) durch das ein-/nachpflegen bisher nicht eingetragener
Waldwege unterstütze.
Und genau dadurch bin ich auf etwas aufmerksam geworden, was meiner
Meinung nach verbessert werden kann.
Allerdings möchte ich diese Änderung, es geht um die Ergänzung von tags,
nicht eigenmächtig vornehmen. Insbesondere da ich nicht weiß ob dieses
hier schon einmal diskutiert und abgelehnt wurde.

Kurze Vorgeschichte:
Bei unserem Urlaub auf Jersey (Kanalinseln) sind wir von "La
Rocque"/Seymour Slipway zum Seymour Tower auf L'Avarison gelaufen, was
nur bei Ebbe möglich ist.  Dabei muß man 2 gully's (In deutsch würde ich
sie Priele nennen, ist aber Felsboden) durchschreiten. Zwischen den
beiden gullys kann man bei auflaufendem Wasser abgeschnitten werden,
weshalb die Jersey Coastguard dort einen Rettungsturm aufgestellt hat,
ähnlich denen im Wattenmeer.
Das es diesen gibt, haben wir erst bemerkt als er in Sicht kam. Ich habe
dann die Koordinaten eingemessen, weil ich ihn in OSM einpflegen wollte,
da er mir auf der OSM-Karte in meinem Garmin nicht angezeigt wurde. -
Auf dem Rückweg ist das Dingen dummerweise kaum bis garnicht zu sehen,
weil diese dünne Stahlrohrkonstruktion vor dem Hintergund (der Insel)
einfach verschwindet.

Wieder daheim bemerke ich, daß der Turm schon eingetragen ist! Für die
Neugierigen: N 49°09.821 W002°01.104

Dort sind "nur" 3 Tags eingetragen:
man_made = tower
name = Refuge Tower
tower:type = observation

Dem tagging kann ich so nicht zustimmen aber das ist eine andere
Geschichte.

Daraufhin habe ich mir die Rettungsbaken vor Cuxhaven mal in JOSM
angeschaut, die auf der Karte ebenfalls nicht angezeigt werden...
Als Beispiel nehme hier mal die Rettungsbake 1 bei N53°54.395
E008°40.068, die wie folgt getaggt ist:

emergeny = marine_refuge
seamark:beacon_special_purpose:colour = black
seamark:conspicuity = conspicuous
seamark:construction = metal
seamark:name = Ret. 1
seamark:reflectivity = conspicuous
seamrak:souce = BfS 53/19 WSA Cuxhaven
seamark:status = permanent
seamarkt:type = beacon_special_purpose

(Nicht nur) Im Wald findet man oft Schutzhütten, die auf allen mir
bekannten und auf OSM basierenden Karten angezeigt werden. - Natürlich
ist mir klar, daß dieses letztendlich Sache der Renderereinstellungen sind.
Allerdings haben alle diese Schutzhütten das tag "amenity = shelter" und
werden mit dem Icon
https://wiki.openstreetmap.org/wiki/File:Shelter-14.svg angezeigt.

Lange Rede, kurzer Sinn: Ich finde es Sinnvoll, die
Rettungsbaken/Rettungstürme ebenfalls mit dem tag "amenity = shelter" zu
ergänzen, wobei ich den Zusatz "shelter_type = emergency" als ergänzende
Information nicht ausschließen möchte, damit diese auf den Karten
dargestellt werden (können). - Das kann Leben retten.

Ich bin auf eure Meinungen gespannt.

Liebe Grüße
Michael (aka Droelfzehn)






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


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

[Talk-us] Meaning of terminal access

[Michael Patrick]

 > How are these tags being used?

Important for logistics. Indicates where certain classes of vehicles can
enter / exit the federally regulated interstate system onto designated
local routes. They are marked with trail blaze signs (
https://dot.ca.gov/-/media/dot-media/programs/traffic-operations/images/sign-ta.jpg
)
Similar to a 'Truck Route' sign (
https://dot.ca.gov/-/media/dot-media/programs/traffic-operations/images/sign-truck-route.gif
).

For one state's example, see
http://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=VEH=35401.5
.
"(d) The Department of Transportation or local authorities may establish a
process whereby access to terminals or services may be applied for upon a
route not previously established as an access route. The denial of a
request for access to terminals and services shall be only on the basis of
safety and an engineering analysis of the proposed access route. ...For
purposes of this subdivision, “terminal” means either of the following:
(1) A facility where freight originates, terminates, or is handled in the
transportation process.
(2) A facility where a motor carrier maintains operating facilities.

See https://dot.ca.gov/programs/traffic-operations/legal-truck-access

Michael Patrick
Data Ferret



Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-de] Frage zum tagging Rettungsbaken

[Droelfzehn (Michael)]

Hallo zusammen!

Von mir lest Ihr kaum, weil ich meist nicht qualifiziert genug bin an
der Diskussion teilzunehmen aber ich lese hier regelmäßig mit und
versuche auch das eine oder andere umzusetzen, wenn es micht betrifft. ;-)

Nun habe ich aber etwas, bei dem ich gerne Eure Meinung hätte.

Ich nutze die OSM Karten oft und gerne für's Geocachen, weshalb ich OSM
(meistens) durch das ein-/nachpflegen bisher nicht eingetragener
Waldwege unterstütze.
Und genau dadurch bin ich auf etwas aufmerksam geworden, was meiner
Meinung nach verbessert werden kann.
Allerdings möchte ich diese Änderung, es geht um die Ergänzung von tags,
nicht eigenmächtig vornehmen. Insbesondere da ich nicht weiß ob dieses
hier schon einmal diskutiert und abgelehnt wurde.

Kurze Vorgeschichte:
Bei unserem Urlaub auf Jersey (Kanalinseln) sind wir von "La
Rocque"/Seymour Slipway zum Seymour Tower auf L'Avarison gelaufen, was
nur bei Ebbe möglich ist.  Dabei muß man 2 gully's (In deutsch würde ich
sie Priele nennen, ist aber Felsboden) durchschreiten. Zwischen den
beiden gullys kann man bei auflaufendem Wasser abgeschnitten werden,
weshalb die Jersey Coastguard dort einen Rettungsturm aufgestellt hat,
ähnlich denen im Wattenmeer.
Das es diesen gibt, haben wir erst bemerkt als er in Sicht kam. Ich habe
dann die Koordinaten eingemessen, weil ich ihn in OSM einpflegen wollte,
da er mir auf der OSM-Karte in meinem Garmin nicht angezeigt wurde. -
Auf dem Rückweg ist das Dingen dummerweise kaum bis garnicht zu sehen,
weil diese dünne Stahlrohrkonstruktion vor dem Hintergund (der Insel)
einfach verschwindet.

Wieder daheim bemerke ich, daß der Turm schon eingetragen ist! Für die
Neugierigen: N 49°09.821 W002°01.104

Dort sind "nur" 3 Tags eingetragen:
man_made = tower
name = Refuge Tower
tower:type = observation

Dem tagging kann ich so nicht zustimmen aber das ist eine andere Geschichte.

Daraufhin habe ich mir die Rettungsbaken vor Cuxhaven mal in JOSM
angeschaut, die auf der Karte ebenfalls nicht angezeigt werden...
Als Beispiel nehme hier mal die Rettungsbake 1 bei N53°54.395
E008°40.068, die wie folgt getaggt ist:

emergeny = marine_refuge
seamark:beacon_special_purpose:colour = black
seamark:conspicuity = conspicuous
seamark:construction = metal
seamark:name = Ret. 1
seamark:reflectivity = conspicuous
seamrak:souce = BfS 53/19 WSA Cuxhaven
seamark:status = permanent
seamarkt:type = beacon_special_purpose

(Nicht nur) Im Wald findet man oft Schutzhütten, die auf allen mir
bekannten und auf OSM basierenden Karten angezeigt werden. - Natürlich
ist mir klar, daß dieses letztendlich Sache der Renderereinstellungen sind.
Allerdings haben alle diese Schutzhütten das tag "amenity = shelter" und
werden mit dem Icon
https://wiki.openstreetmap.org/wiki/File:Shelter-14.svg angezeigt.

Lange Rede, kurzer Sinn: Ich finde es Sinnvoll, die
Rettungsbaken/Rettungstürme ebenfalls mit dem tag "amenity = shelter" zu
ergänzen, wobei ich den Zusatz "shelter_type = emergency" als ergänzende
Information nicht ausschließen möchte, damit diese auf den Karten
dargestellt werden (können). - Das kann Leben retten.

Ich bin auf eure Meinungen gespannt.

Liebe Grüße
Michael (aka Droelfzehn)






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