[Diversity-talk] Community track at SOTM

[Heather Leson]

Hi I chatted briefly with Trudy. Who would like to help me curate a track
on community for SOTM?

Last weekend I went to FOSDEM. There were some great talks that relate to
our work - I curated a list (videos and slides are online)

https://www.openstreetmap.org/user/Heather%20Leson/diary/392119

heather

Heather Leson
heatherle...@gmail.com
Twitter/skype: HeatherLeson
Blog: textontechs.com
___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Joseph Eisenberg]

> Re: "Similarly, type=route relations (road, bicycle, hiking, equestrian...) 
> enter OSM from ODbL-compatible government-published maps, yet remain unsigned 
> (or poorly signed) in the real world."

Please do not add this section. Most types of route relation should
only be mapped if they are actually signed. Some which are fixed-route
public services can be mapped based on actually riding the route,
which is also a real-world method of verification which does not
depend on consulting an external map or document. I do not think the
"good practice" page should mention mapping routes which are not
verifiable in the real world, which only exist on paper. While some
mappers like to add such things (like "proposed" bicycle routes or
hiking routes which only exist in guidebooks and have no signs), this
is not a good practice.

> Re: "on a government map, by legal / statutory decree, from data 
> authoritatively published on a website"

These examples are not "good practice" sources for openstreetmap.
While many mappers import data from such sources, there is no "value
added" in the case that mappers are unable to confirm if the
government or "authoritative" data is accurate or inaccurate. Since
the data in Openstreetmap can be changed at any time, and often by
mistakes caused by new mappers, the authoritative database or source
will always be better for database users to consult directly, unless
openstreetmap can improve the originally imported data by checking it
against reality.

Remember, this is the "good practice" page we are talking about
editing, not the "how things really are done" page: we want to focuse
on the "Gold Standard", best practices.

- Joseph Eisenberg

On 2/9/20, stevea  wrote:
> Done:
>
> https://wiki.osm.org/wiki/Talk:Good_practice#Supplementing_and_clarifying_the_On_The_Ground_.22rule.22
>
> Follow it there, if you like.
>
> SteveA
>
>> On Feb 8, 2020, at 12:04 PM, Yuri Astrakhan 
>> wrote:
>>
>> I am in favor of this or similar language.  I think for a more vote-like
>> discussion it might be better to use the wiki talk page (easier to add +1s
>> and short comments).
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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

Re: [Talk-it] CAI non attribuisce?

[Lorenzo Perone]

Ciao,
nei credits c'è.
Lorenzo

Il sab 8 feb 2020, 23:02 Cascafico Giovanni  ha
scritto:

> Mi sembra che questo sito [1] non abbia attribuito la mappa OSM...
> forse è un problema del mio browser? Mi chiedo anche se sia
> controllato dal CAI o meno.
>
>
> [1] https://mappasentieroitalia.cai.it
>
> ___
> 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

[Talk-it] CAI non attribuisce?

[Cascafico Giovanni]

Mi sembra che questo sito [1] non abbia attribuito la mappa OSM...
forse è un problema del mio browser? Mi chiedo anche se sia
controllato dal CAI o meno.


[1] https://mappasentieroitalia.cai.it

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

[OSM-talk] Acknowledgement for the wiki documentation

[Daniel Capilla]

Hi,

I've been working on the translation of the wiki into Spanish for a long 
time, both creating new translations and updating the translations that 
become obsolete. In all this time I have been able to check the 
evolution of some pages of documentation in English, the way in which 
they have expanded in content over time and clarifying cases of use of 
tags that could be confusing initially.


I have sent this message to the mailing list just to thank all users and 
contributors who help documenting the use of tags, projects, mappers' 
guides and other documentation pages on the OSM Wiki. It is an important 
work, a much appreciated and very valuable effort.


Thanks to all of you!

Greetings from Spain.

Regards,

Daniel


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

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[stevea]

Done:

https://wiki.osm.org/wiki/Talk:Good_practice#Supplementing_and_clarifying_the_On_The_Ground_.22rule.22

Follow it there, if you like.

SteveA

> On Feb 8, 2020, at 12:04 PM, Yuri Astrakhan  wrote:
> 
> I am in favor of this or similar language.  I think for a more vote-like 
> discussion it might be better to use the wiki talk page (easier to add +1s 
> and short comments).

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

Re: [talk-au] SSSI National Bushfire Recovery Map-a-thon - Sunday 9th Feb

[Sebastian S.]

I agree that putting the building on the map should rank higher than giving it 
a lifecycle or damaged attribute that hard to assess from the image quality. 

This is also the approach I recall from HOT disaster mapping. Roads and 
building from satellite, destruction details from ground crew. (Admittedly I 
might be wrong here).

On 8 February 2020 6:44:30 pm AEDT, John Bryant  wrote:
>>
>> *Maybe swap across to LPI imagery & just map all the buildings &
>other
>> POI, without worrying about damage? That would be a huge bonus as far
>as
>> OSM is concerned, but wouldn't actually do anything at all for the
>disaster
>> recovery side of things?*
>>
> This seems like a productive idea to me... capturing buildings in
>bushfire-affected areas could produce a useful input to spatial
>analyses. I
>don't know what the agencies already have in this regard though.
>
>On Sat, 8 Feb 2020 at 17:14, Phil Wyatt  wrote:
>
>> Some new imagery is being uploaded... not sure on resolution
>>
>>
>> Cheers - Phil,
>> On the road with his iPad
>>
>> On 8 Feb 2020, at 5:49 pm, Graeme Fitzpatrick 
>> wrote:
>>
>> 
>>
>>
>>
>> On Sat, 8 Feb 2020 at 16:24, Ewen Hill  wrote:
>>
>>> Sadly the Planet quality appears less than optimal.
>>>
>>
>> You're not wrong!
>>
>>
>>> If I look at the town of Cobargo where there were buildings lost
>just
>>> north east of the Narira Creek Highway crossing, I can't tell.what
>has been
>>> destroyed, damaged or otherwise. :
>>> https://tasks.hotosm.org/project/7898?task=591
>>>
>>
>> No, there's no way of telling if a building has been damaged - I'm
>been
>> mapping for a while & I couldn't even pick them as buildings, without
>> changing to a different set of imagery. Where I was just looking I
>couldn't
>> even tell if the area had actually been burnt over - it all looked
>like
>> normal dry grassland to me?
>>
>> I think we really need to come up with a backup plan for this event
>and
>>> quietly push SSSI towards that.
>>>
>>
>> Maybe swap across to LPI imagery & just map all the buildings & other
>POI,
>> without worrying about damage? That would be a huge bonus as far as
>OSM is
>> concerned, but wouldn't actually do anything at all for the disaster
>> recovery side of things?
>>
>>
>>> We don't want people's first taste of OSM to be a poor one.
>>>
>>
>> No, & I agree with you that it won't be a good, first look :-(
>>
>>   Thanks
>>
>> Graeme
>>
>> ___
>> Talk-au mailing list
>> Talk-au@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
>>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Diversity-talk] [Osmf-talk] First Meeting of Diversity and Inclusion Special Committee

[Mikel Maron]

There’s really no good time that works universally. These won’t be the only 
meetings or way to get involved, they’re just to get things moving.

Mikel

On Saturday, February 8, 2020, 1:40 PM, Philip Barnes  
wrote:

On Sat, 2020-02-08 at 16:12 +, Mikel Maron wrote:
To accommodate time zones, we’ll hold this initial meeting twice, the second at 
1700 UTC on the same day, Wednesday February 12. I’ve blocked out an hour for 
each, but if you can only attend a portion that’s fine too.

Hi Mikel
Would it not be better to hold these meetings on a weekend when more people are 
likely to be available?
Whilst Europe is very much awake at these times, 14:00 is also working time, 
17:00 is end of work time, commute time and woking time in North America. Phil 
(trigpoint)



___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org



___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Yuri Astrakhan]

I am in favor of this or similar language.  I think for a more vote-like
discussion it might be better to use the wiki talk page (easier to add +1s
and short comments).

On Sat, Feb 8, 2020 at 2:59 PM stevea  wrote:

> I don't know if here or https://wiki.osm.org/wiki/Talk:Good_practice is a
> better place to discuss and eventually insert these suggested improvements
> into https://wiki.osm.org/wiki/Good_practice#Verifiability (and its first
> section, "Map what's on the ground").
>
> I suggest adding these essences of this thread there:
>
> "'Independent verifiability' is a crucial component of the Good Practice
> of mapping what is on the ground, as sometimes there IS no evidence
> on-the-ground that a map feature should be appropriately tagged anything in
> particular.  For example, some boundaries are effectively invisible, but
> OSM maps them (and should).  Also, there are no or few signs which say
> "Pacific Ocean" or "Rocky Mountains," yet OSM authoritatively maps these
> natural=* features with an agreed-correct name=* tag.  Similarly, there are
> routes (road, bicycle, hiking, equestrian...) which might exist on a
> government-published map (and hence are ODbL-compatible) yet remain
> unsigned (or poorly signed) in the real world.  From what authority must we
> determine the source "verifiability" of these "invisible" or "unsigned" map
> features?  As long as these are "independently verifiable" (by a government
> map, legal / statutory decree, data authoritatively published on a website,
> by unanimous agreement among locals and a wider public or at least with
> very wide consensus), the map feature with its verifiable tags may be
> entered into OSM following Good Practice.  'Independent verifiability'
> means any member of the public, freely, anytime and with no special
> privileges can 'consult the source' and verify the data."
>
> I'm simply tossing that out here, if it shouldn't stick, please fix it.  I
> think it important that the phrasing is first vetted (here or on the Talk
> page) and I do think something like this should be entered into our
> Good_practice wiki to clarify OTG as we have discussed it here.
>
> Thanks in advance for any brief review and comments / suggestions you
> might offer,
> SteveA
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[stevea]

I don't know if here or https://wiki.osm.org/wiki/Talk:Good_practice is a 
better place to discuss and eventually insert these suggested improvements into 
https://wiki.osm.org/wiki/Good_practice#Verifiability (and its first section, 
"Map what's on the ground").

I suggest adding these essences of this thread there:

"'Independent verifiability' is a crucial component of the Good Practice of 
mapping what is on the ground, as sometimes there IS no evidence on-the-ground 
that a map feature should be appropriately tagged anything in particular.  For 
example, some boundaries are effectively invisible, but OSM maps them (and 
should).  Also, there are no or few signs which say "Pacific Ocean" or "Rocky 
Mountains," yet OSM authoritatively maps these natural=* features with an 
agreed-correct name=* tag.  Similarly, there are routes (road, bicycle, hiking, 
equestrian...) which might exist on a government-published map (and hence are 
ODbL-compatible) yet remain unsigned (or poorly signed) in the real world.  
From what authority must we determine the source "verifiability" of these 
"invisible" or "unsigned" map features?  As long as these are "independently 
verifiable" (by a government map, legal / statutory decree, data 
authoritatively published on a website, by unanimous agreement among locals and 
a wider public or at least with very wide consensus), the map feature with its 
verifiable tags may be entered into OSM following Good Practice.  'Independent 
verifiability' means any member of the public, freely, anytime and with no 
special privileges can 'consult the source' and verify the data."

I'm simply tossing that out here, if it shouldn't stick, please fix it.  I 
think it important that the phrasing is first vetted (here or on the Talk page) 
and I do think something like this should be entered into our Good_practice 
wiki to clarify OTG as we have discussed it here.

Thanks in advance for any brief review and comments / suggestions you might 
offer,
SteveA
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] Still too many universities in Cambridge

[Phillip Barnett]

And in fact David Earl deserves recognition for pretty much single-handedly 
doing the original basic mapping of Cambridge at street level. (I did about 1% 
of it at the time, but had the excuse of very young children taking my 
attention)

Sent from my iPhone

> On 8 Feb 2020, at 14:30, Richard Fairhurst  wrote:
> 
> Dave F wrote:
>> CU wanted a new site map. They paid someone to provide it for 
>> them. Which is fine, but please don't suggest they're 
>> contributions are superior to those of any anybody else. 
>> Especially when they decided to knowingly go against accepted 
>> tagging procedures.
> 
> I think that's a little harsh - David Earl mapped the university in the
> _very_ early days of the project. There's stuff there dating back to
> 2006/2007. Cambridge was the first place to be mapped in great detail in the
> UK - even in 2011 I remember giving a talk at Oxford Geek Nights where I
> could still hold Cambridge up as an exemplar of how to do it. You can
> imagine how well that went down in Oxford. ;)
> 
> So it wasn't really "going against accepted tagging procedures", because
> tagging was still very much evolving back then. Fully in agreement that the
> time has come to update the tagging, but that's just a result of OSM
> changing - there's no need for any rancour against the original mappers.
> 
> Richard
> 
> 
> 
> --
> Sent from: http://gis.19327.n8.nabble.com/Great-Britain-f5372682.html
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [talk-ph] is_in tags in the Philippines

[Eugene Alvin Villar]

Just another data point to add to the discussion:

JOSM currently warns that is_in=* tags are deprecated:
https://josm.openstreetmap.de/changeset/14917/josm

Generally, tagging suggestions in JOSM are not usually controversial
(unlike some of iD's tagging suggestions). Therefore, I usually delete such
tags if they are redundant to administrative boundary relations.

On the other hand, I would preserve them, or even add them (like for Brgy.
Quinawan, Bagac, Bataan[1]), if the boundary relation doesn't exist yet.

[1] https://www.openstreetmap.org/node/3085704286/history

On Thu, Jan 23, 2020, 3:50 PM Eugene Alvin Villar,  wrote:

> I generally agree except for the cases where the tag value corresponds to
> an administrative entity that already has a boundary relation. In which
> case I would then remove the tag.
>
> On Thu, Jan 23, 2020, 10:16 AM Erwin Olario,  wrote:
>
>>
>> Until we have a complete, and accurate sub-national boundary polygons in
>> the Philippines, I'd like to suggest that we avoid removing is_in tags, as
>> these may still contain valuable information that cannot be deduced from
>> still non-existent boundaries.
>>
>> What do you think?
>>
>> /erwin
>>
>>
>> - - - - - - - - - - - - - - - - - - -
>> » email: erwin@ *n**gnu**it**y**.xyz*
>>  | gov...@gmail.com
>> » mobile: https://t.me/GOwin
>> » OpenPGP key: 3A93D56B | 5D42 7CCB 8827 9046 1ACB 0B94 63A4 81CE 3A93
>> D56B
>> ___
>> talk-ph mailing list
>> talk-ph@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ph
>>
>
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [Diversity-talk] [Osmf-talk] First Meeting of Diversity and Inclusion Special Committee

[Philip Barnes]

On Sat, 2020-02-08 at 16:12 +, Mikel Maron wrote:
> To accommodate time zones, we’ll hold this initial meeting twice, the
> second at 1700 UTC on the same day, Wednesday February 12. I’ve
> blocked out an hour for each, but if you can only attend a portion
> that’s fine too.
Hi Mikel

Would it not be better to hold these meetings on a weekend when more
people are likely to be available?

Whilst Europe is very much awake at these times, 14:00 is also working
time, 17:00 is end of work time, commute time and woking time in North
America.
 
Phil (trigpoint)





___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[stevea]

Very well stated, Colin.  I agree that "independent verifiability" is at the 
heart of OTG and what we mean to distill from it as crucially important and a 
tenet of OSM that we can all agree upon (well, I hope so, anyway).

By explicitly stating that John Random Public can "consult the source" (freely, 
in all senses) to determine "what is" even (or especially) if something is NOT 
on-the-ground, we actually DO largely encompass many of the exceptions of "but 
I can't SEE it on the ground."  We may have more work to do to be more 
explicit, but this goes a long way:  thank you!

SteveA

> On Feb 8, 2020, at 9:42 AM, Colin Smale  wrote:
> 
> On 2020-02-08 18:03, stevea wrote:
> 
>> See, "the on the ground rule," to the best of my ability to determine it (an 
>> exception is your opinion as you explicitly express here, and that's part of 
>> the problem with it), isn't clearly defined and it needs the elasticity of 
>> such ad hoc exceptions.  It doesn't say (explicitly, anywhere, except in 
>> your exception) "we ask people there and look at books, other maps, 
>> Wikipedia, travel books, organizations...if the name is used in reality."  
>> You do (here, as an "exception," by way of clarifying your understanding of 
>> OTG) but if all of that is true, OSM should say so:  formally and as fully 
>> as possible.
>> 
> The most important aspect of the "on the ground" rule is that things are 
> independently verifiable, i.e. given the evidence, anybody would come to the 
> same conclusion. Physical evidence is obviously very useful - for example, 
> either a highway is present, or it is not. But other sources, provided they 
> are freely accessible, can also provide facts that are sufficiently 
> verifiable. In the case of the US-CA border, I guess the treaty or whatever 
> is publicly accessible, so there can be no arguments about where the border 
> is in a legal sense. Of course not all boundaries are fully specified in 
> treaties, but I suspect this one is.
>  
> So I suggest the "On The Ground" rule should be replaced by a requirement for 
> independent verifiability; our traditional definition of OTG is sufficient 
> but not necessary for compliance.
>  
> Independent viability means (to me) a random member of the public, with no 
> special privileges, and without payment, and at any time, should be able to 
> "consult the source".
>  
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Colin Smale]

On 2020-02-08 18:03, stevea wrote:

> See, "the on the ground rule," to the best of my ability to determine it (an 
> exception is your opinion as you explicitly express here, and that's part of 
> the problem with it), isn't clearly defined and it needs the elasticity of 
> such ad hoc exceptions.  It doesn't say (explicitly, anywhere, except in your 
> exception) "we ask people there and look at books, other maps, Wikipedia, 
> travel books, organizations...if the name is used in reality."  You do (here, 
> as an "exception," by way of clarifying your understanding of OTG) but if all 
> of that is true, OSM should say so:  formally and as fully as possible.

The most important aspect of the "on the ground" rule is that things are
independently verifiable, i.e. given the evidence, anybody would come to
the same conclusion. Physical evidence is obviously very useful - for
example, either a highway is present, or it is not. But other sources,
provided they are freely accessible, can also provide facts that are
sufficiently verifiable. In the case of the US-CA border, I guess the
treaty or whatever is publicly accessible, so there can be no arguments
about where the border is in a legal sense. Of course not all boundaries
are fully specified in treaties, but I suspect this one is. 

So I suggest the "On The Ground" rule should be replaced by a
requirement for independent verifiability; our traditional definition of
OTG is sufficient but not necessary for compliance. 

Independent viability means (to me) a random member of the public, with
no special privileges, and without payment, and at any time, should be
able to "consult the source".___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[stevea]

On Feb 8, 2020, at 2:58 AM, Rory McCann  wrote:
> On 07.02.20 20:12, stevea wrote:
>> A well-known example is (national, other) boundaries, which
>> frequently do not exist "on the ground,"
> National borders don't exist on the ground? huh? Have you ever actually
> _crossed_ an international border? I assure you they exist on the
> ground. From large infrastructure, to changes in the paint colour on
> roads, one can nearly always *see* where a border is.

I didn't say "always" (I said "frequently," though I was being parochial / 
local to me).  Between USA and Canada, for thousands (and thousands) of 
kilometers, the national border is entirely invisible.  True, in places, it 
exists in an observable way (some stone markers, border crossings with 
paint-on-asphalt, even a fence or wall here or there), but I'd even say 
"mostly," the USA-Canada national border simply "isn't there:"  nothing 
on-the-ground, that is.  We (OSM) cannot say that "nearly always" characterizes 
how one can *see* where a border is.  And yes, I have crossed international 
borders, dozens, maybe hundreds of times.

By contrast (thanks for the link and photo, Minh), our wiki 
https://wiki.osm.org/wiki/United_States/Boundaries#National_boundary shows the 
stark demarcation between San Diego (California, USA) and Tijuana (Baja 
California, México), Having frequently crossed it, I know this boundary well 
and it is an example of an OBSERVABLE boundary OTG.  But again, not all are.  
Nor are MANY things in OSM "observable OTG" like this, yet they remain in the 
map (and more are added each day).  OSM should explicitly acknowledge this.

>> Other examples include large bodies of water and mountain ranges.
>> I've lived on the Pacific coast most of my life and been to dozens of
>> beaches, but never once on any beach have I seen a sign which reads
>> "Pacific Ocean."  Same with no signs at the edge of or in the middle
>> of "Rocky Mountains" or "The Alps."  (I've been, and I haven't seen).
>> Yet, OSM maps oceans and mountain ranges.  How do we know their names
>> without anything on the ground?
> We ask people there. We look at books, at maps, at whether there is a 
> detailed Wikipedia article on the topic, do are travel books published that 
> refer to this area as that, do organisations that cover that area use that 
> term. We look to see if the name is _used in reality_.
> 
> That's the "on the ground rule". IMO "on the ground" refers to "observable 
> reality".

See, "the on the ground rule," to the best of my ability to determine it (an 
exception is your opinion as you explicitly express here, and that's part of 
the problem with it), isn't clearly defined and it needs the elasticity of such 
ad hoc exceptions.  It doesn't say (explicitly, anywhere, except in your 
exception) "we ask people there and look at books, other maps, Wikipedia, 
travel books, organizations...if the name is used in reality."  You do (here, 
as an "exception," by way of clarifying your understanding of OTG) but if all 
of that is true, OSM should say so:  formally and as fully as possible.

Such fuzzy semantics land us where we are:  in ambiguity.  Let us acknowledge 
that such exceptions (and there are many of them) exist and best deserve to be 
explicitly described.  We should do so for the betterment of the rule.  And, 
"rule" becomes "good guideline, applicable where it can be easily and 
unambiguously applied, but with sensible exceptions we can largely but probably 
not exhaustively delineate."

With such dialog, we get closer, yes.

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

Re: [OSM-talk] OSM/LondonOSM | Re: Crimea situation - on the ground

[Yuri Astrakhan]

Thanks Rory, that's an interesting case.  One thing of note is grouping
names by language/dialect is fairly common but still arbitrary division --
i.e. it assumes that a group of people speaking one language/dialect have
no contradictions in naming something.  But just like we should not assume
language is the same as a location for wiki documentation, names could also
differ depending on location rather than name.

A case to the point:  Russian speakers from New York tend to say "in
Manhattan" (meaning -- in the city/borough of Manhattan), where as Russian
speakers from everywhere else tend to say "on Manhattan" (on an island of
Manhattan). I suspect this has cultural roots -- there was a popular song
with words "live on Manhattan" that recently made that expression popular
everywhere except for the Russian-speaking NYC populace.  Of course this is
not something we need to document in OSM, but it highlights that language
is not homogeneous with naming and just makes a fun story :)

On Sat, Feb 8, 2020 at 6:22 AM Rory McCann  wrote:

> On 07.02.20 20:22, Yuri Astrakhan wrote:
> > (e.g. two fairly large groups of people could refer to the same
> > place/object by different names). ... the map should be able to
> > reflect difference of opinions to some "reasonable" degree (an
> > intentionally vague term).
> One useful example of that is a city in the north west of the island of
> Ireland, called (in English) either Derry or Londonderry. Everyone
> agrees on the Irish name (`name:ga`) (
gaDoire
). OSM's
> multilingual tagging scheme, but for dialects, are used to differentiate
> the Hiberno-English (en_IE) name (
en-IEDerry
) from the
> British-English (en_GB) term (
en-GBLondonderry
). The `name`
> tag uses the commonly used compromise. That approach could work for
> other areas.
>
> RFC 1766 (for IETF language tags) appears to allow quite detailed
> specification of languages & areas, and could be useful.
>
> https://www.openstreetmap.org/node/267762522
> https://tools.ietf.org/html/rfc1766
> https://en.wikipedia.org/wiki/IETF_language_tag
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Diversity-talk] [Osmf-talk] First Meeting of Diversity and Inclusion Special Committee

[Mikel Maron]

To accommodate time zones, we’ll hold this initial meeting twice, the second at 
1700 UTC on the same day, Wednesday February 12. I’ve blocked out an hour for 
each, but if you can only attend a portion that’s fine too.
Expect we’ll discuss the scope of work laid out by the Board, sketch initial 
work plans, and figure out logistics and timing and structure of future 
meetings. I’d rather not “chair” the meetings after this, so if you’re 
interested we can discuss at either meeting and decide after both. I’ll take 
minutes if no one else volunteers and circulate after.

Mikel

On Thursday, February 6, 2020, 1:44 PM, Mikel Maron  
wrote:

 Last month, the OSMF adopted this Diversity Statement [1] and appointed a 
committee [2] to compile research and undertake new research on our diversity, 
identify root causes that contribute to any shortfalls, and make 
recommendations to help resolve issues and improve. 
If you're interested to take part, join an upcoming initial meeting of the 
committee. We're holding a first meeting on Wednesday February 12 at 1400 UTC 
[3] on Mumble [4] (in the public OSMF Board of Directors room). Please join if 
you'd like to contribute. If you're unavailable at that time, let us know other 
times that might work, and we can schedule another kickoff meeting in addition.
[1] https://wiki.osmfoundation.org/wiki/Diversity_Statement[2] 
https://hackmd.io/ZG8x44H4Skq0CPkcrMTB6A?view[3] Timezone converter: 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=DISC+Meeting=20200212T14=1440[4]
 How to use Mumble: https://wiki.openstreetmap.org/wiki/Mumble
-Mikel

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



___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [OSM-talk-ie] OSM at LoveDataWeek 2020 - Maynooth University

[Dave Corley]

Umap is another good one to use for those who want to overlay additional
data / information onto a base map

On Sat 8 Feb 2020, 14:51 Peter Mooney,  wrote:

> Hello everyone,
>
> I'm giving a general overview talk about OpenStreetMap in Maynooth
> University next week, as part of Love Data Week 2020. Details are here [1].
>
> I only have an hour so I want to show attendees what kinds of applications
> OpenStreetMap is being used for in Ireland and beyond. This will include
> quick examples of downloading data, using Turbo Overpass online, and a very
> basic map using Leaflet. I'll be showing the work of OSM IE (example the
> recent Kilkenny work), Townlands, Hieki's visualisations, etc.
>
> If you have any other really interesting examples of OSM use which would be
> good for a general audience, please let me know and I'd be delighted to
> include it.
>
> I will make my slides openly available in ODP format afterwards, if they
> are useful for someone else.
>
> With every best wish,
>
> Peter
>
> [1] https://www.maynoothuniversity.ie/library/events/love-data-week-2020
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

[OSM-talk-ie] OSM at LoveDataWeek 2020 - Maynooth University

[Peter Mooney]

Hello everyone,

I'm giving a general overview talk about OpenStreetMap in Maynooth
University next week, as part of Love Data Week 2020. Details are here [1].

I only have an hour so I want to show attendees what kinds of applications
OpenStreetMap is being used for in Ireland and beyond. This will include
quick examples of downloading data, using Turbo Overpass online, and a very
basic map using Leaflet. I'll be showing the work of OSM IE (example the
recent Kilkenny work), Townlands, Hieki's visualisations, etc.

If you have any other really interesting examples of OSM use which would be
good for a general audience, please let me know and I'd be delighted to
include it.

I will make my slides openly available in ODP format afterwards, if they
are useful for someone else.

With every best wish,

Peter

[1] https://www.maynoothuniversity.ie/library/events/love-data-week-2020
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-GB] Still too many universities in Cambridge

[Dave F via Talk-GB]

On 06/02/2020 16:49, Phillip Barnett wrote:

And here is the email from the guy who did the original mapping, the last time 
this came up, including his reasoning for the amenity Tag rather than building 
tag https://lists.openstreetmap.org/pipermail/talk-gb/2015-May/017457.html


Note the time it took to write just that one post was longer than it 
would have taken to convert the OSM data & a few lines code to rectify 
the problem.


There isn't constant change. In this instance is was created incorrectly 
& needs to be fixed once.


His claim about building=university is moot. 'One feature, one OSM 
element' has been long established.


DaveF


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

Re: [OSM-talk-fr] stabilité et stat sur la disponibilité du fond OSM org

[Jacques Lavignotte]

Impressionnant !


Le 08/02/2020 à 13:57, Baptiste Jonglez a écrit :


   
https://munin.openstreetmap.org/openstreetmap.org/tile.openstreetmap.org/squid_times_http.html



Si tu veux savoir où est chaque serveur : 
https://hardware.openstreetmap.org/#tile-caches
Et quel serveur(s) de cache est utilisé pour chaque pays : 
https://dns.openstreetmap.org/tile.openstreetmap.org.html


Merci, Jacques

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

Re: [Talk-GB] Still too many universities in Cambridge

[Richard Fairhurst]

Dave F wrote:
> CU wanted a new site map. They paid someone to provide it for 
> them. Which is fine, but please don't suggest they're 
> contributions are superior to those of any anybody else. 
> Especially when they decided to knowingly go against accepted 
> tagging procedures.

I think that's a little harsh - David Earl mapped the university in the
_very_ early days of the project. There's stuff there dating back to
2006/2007. Cambridge was the first place to be mapped in great detail in the
UK - even in 2011 I remember giving a talk at Oxford Geek Nights where I
could still hold Cambridge up as an exemplar of how to do it. You can
imagine how well that went down in Oxford. ;)

So it wasn't really "going against accepted tagging procedures", because
tagging was still very much evolving back then. Fully in agreement that the
time has come to update the tagging, but that's just a result of OSM
changing - there's no need for any rancour against the original mappers.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Great-Britain-f5372682.html

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

Re: [Talk-GB] Still too many universities in Cambridge

[Dave F via Talk-GB]

On 06/02/2020 15:48, Brian Prangle wrote:

"OSM is not beholden to data consumers.
They take the data 'as is'. That includes any amendments

My planned amendment can always be reversed if there is a valid reason.
Upsetting CU isn't one"

  Not a great way to build a community when the data user in question put in
a lot of resource in order to create the OSM data in the firstplac
e


CU wanted a new site map. They paid someone to provide it for them. 
Which is fine, but please don't suggest they're contributions are 
superior to those of any anybody else. Especially when they decided to 
knowingly go against accepted tagging procedures. Many of us "put in a 
lot of resource".


They should expect their incorrect data to be rectified just as any of 
contributor should. I'm mildly irritated that these corrections have to 
be done by those who didn't create the errors in the first place.


DaveF

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

Re: [Talk-GB] "British Islands" (was "OSMUK-in-a-box")

[Andy Townsend]

 > I've been looking at IoM, Jersey, and Guernsey which AFAIK have no coverage in the Community Index. As you say, it uses https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2 country codes via the countryCoder so I'm expanding coverage to ["gb", "gg", "je", "im"]. I believe that there may be an issue in how Community Index calls Country Coder and have raised https://github.com/osmlab/osm-community-index/issues/333Yes - I couldn't get lists to work either (of geojsons).  I assumed "it's great at what it does but it doesn't do everything" (and to be fair most of what it doesn't do is pretty well documented).   Best Regards,Andy   ___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] "British Islands" (was "OSMUK-in-a-box")

[Jez Nicholson]

Great...then as far as Northern Ireland is concerned then I think that the
Community Index has it right already. It allows for the overlap or OSMUK
and OSMIE, Talk-GB and Talk-IE

I've been looking at IoM, Jersey, and Guernsey which AFAIK have no coverage
in the Community Index. As you say, it uses
https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2 country codes via the
countryCoder so I'm expanding coverage to ["gb", "gg", "je", "im"]. I
believe that there may be an issue in how Community Index calls Country
Coder and have raised
https://github.com/osmlab/osm-community-index/issues/333

On Fri, Feb 7, 2020 at 11:32 AM Andy Townsend  wrote:

> On 07/02/2020 10:55, Jez Nicholson wrote:
> > Personally, I interpret the coverage of Talk-GB and OSMUK to be the
> > same, i.e. Northern Ireland is officially under OSMUK, but for
> > practical reasons mappers may want to interact with OSMIEand the
> > same for Talk-GB + Talk-IE.
>
> I think that part of the reason historically was that older
> out-of-copyright maps (and things like townlands) were common across the
> island of Ireland.
>
> Even if it was "overclaiming" I don't think that there would be a
> particular problem with talk-gb also being included on the list for NI
> at https://openstreetmap.community/ - the worst that could happen would
> be that someone would get an answer to their question (which might also
> include a mention of various IE resources).  I recently expanded the
> "East Midlands" coverage north a bit to reflect occasional meet-ups in
> Sheffield and the fact that we've had people attending from further
> north again.
>
>
> >
> > This could make the situation of gb geojson simpler. Do you know where
> > they've defined gb? I can't see it.
>
> It uses the iD editor's country coder.  The documentation for that is at
>
> https://github.com/ideditor/country-coder#readme
>
> There's a list in there of what it does and what it doesn't do.
>
> Best Regards,
>
> Andy
>
>
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] stabilité et stat sur la disponibilité du fond OSM org

[Baptiste Jonglez]

Salut,

Si tu t'intéresse à la performance du fond de carte OSM.org, une métrique
disponible facilement est le temps de réponse médian au niveau de chaque
cache Squid :

  
https://munin.openstreetmap.org/openstreetmap.org/tile.openstreetmap.org/squid_times_http.html

C'est très variable selon le serveur de cache (à cause du géo-balancing
DNS), mais c'est globalement pas très bon.  En même temps c'est une infra
avec quasi zéro budget, proche de la saturation, sans aucune garantie de
service, qui n'a pas vocation à être utilisée de façon commerciale, etc.

Si tu veux savoir où est chaque serveur : 
https://hardware.openstreetmap.org/#tile-caches
Et quel serveur(s) de cache est utilisé pour chaque pays : 
https://dns.openstreetmap.org/tile.openstreetmap.org.html

Du coup je rejoins les autres réponses, pour un usage un peu sérieux (et
comparable en performance à Google Maps) il faut aller voir ailleurs :

  https://wiki.openstreetmap.org/wiki/FR:Services_commerciaux_bas%C3%A9s_sur_OSM
  https://wiki.openstreetmap.org/wiki/Commercial_OSM_Software_and_Services

Baptiste

On 07-02-20, Jérôme Seigneuret wrote:
> Bonjour,
> 
> A t'on des stat sur la stabilité et la disponibilité du fond OSM merci

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



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

Re: [OSM-talk-fr] Équitation et attributs proposés

[marc marc]

Le 08.02.20 à 13:21, Arnaud Champollion a écrit :
> beaucoup d'attributs "proposés" mais pas validés.
> 
> Est-ce que ça veut dire que pour l'instant on ne les utilise pas ?

dans osm, tout le monde est libre d'utiliser n'importe quel tags.
un tag validé est simplement un tag qui a fait l'objet d'une discussion
au niveau mondial et qui au moment du vote a paru être de qualité.
c'est totalement indépendent d'être présent ou pas dans la bdd,
être ou pas utilisé par le rendu par défaut ou par n'importe quel autre
rendu ou par une application
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Équitation et attributs proposés

[Philippe Verdy]

note: certains attributs documentés ne sont pas rendus.

Exemple les obstacles fixes de saut équestres, il manque la prise en compte
de certaines valeurs de barrier=*, pour les pistes de steeplechase; on
pourrait tricher en indiquant barrier=gate ou barrier=fence ou
barrier=hedge, mais ce serait taguer pour le rendu et oublier la sémantique
si ce n'est pas un portail, une clôture ou une haie non supposée pouvoir
être "traversée" en sautant par dessus..., et les rivières aussi ne sont
pas des "gués" où mettre un "ford=yes".

D'autres attributs concernent les surfaces de "carrière" hippique,
couvertes ou extérieures (cas le plus courant pour plein de centres
hippiques, sans courses, ce ne sont pas des champs agricoles), et les box
(hôtels pour chevaux: pas vraiment une ferme).

Les grands hippodromes connus en France ou au Royaume-Uni (Longchamps,
Auteuil, Deauville, Londres) ont un rendu très partiel, mais il y a plein
d'autres petits hippodromes et encore plus de centres équestres ouverts au
public. On a oublié aussi l'imposant patrimoine historique du temps où le
cheval (ou autres montures) était encore partout, pour le travail, la
course, le loisir et les déplacements quotidiens, avant le cheval-vapeur.




Le sam. 8 févr. 2020 à 13:22, Arnaud Champollion <
arnaud.champoll...@linux-alpes.org> a écrit :

> Bonjour,
>
> Ma question concerne le thème équestre, mais aussi plus largement les
> attributs "proposés".
>
> Cette page https://wiki.openstreetmap.org/wiki/FR:%C3%89quitation
>
> est justement très complète et documente beaucoup d'attributs "proposés"
> mais pas validés.
>
> Est-ce que ça veut dire que pour l'instant on ne les utilise pas ?
>
> Je suis en ce moment sur ce centre équestre
> https://www.openstreetmap.org/#map=18/43.57627/5.07125
>
> et je compte dans un deuxième temps m'occuper de celui-ci
> https://www.openstreetmap.org/#map=17/44.13293/6.23850
>
> C'est tentant de tout mapper selon cette page du wiki, mais j'ai un
> doute sur le fait d'utiliser les attributs non validés.
>
> Merci
>
> --
> Arnaud Champollion
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Équitation et attributs proposés

[Arnaud Champollion]

Bonjour,

Ma question concerne le thème équestre, mais aussi plus largement les 
attributs "proposés".


Cette page https://wiki.openstreetmap.org/wiki/FR:%C3%89quitation

est justement très complète et documente beaucoup d'attributs "proposés" 
mais pas validés.


Est-ce que ça veut dire que pour l'instant on ne les utilise pas ?

Je suis en ce moment sur ce centre équestre 
https://www.openstreetmap.org/#map=18/43.57627/5.07125


et je compte dans un deuxième temps m'occuper de celui-ci 
https://www.openstreetmap.org/#map=17/44.13293/6.23850


C'est tentant de tout mapper selon cette page du wiki, mais j'ai un 
doute sur le fait d'utiliser les attributs non validés.


Merci

--
Arnaud Champollion


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

Re: [Talk-se] Malmö och Örnsköldsvik saknas på vektorkarta

[Essin]

Hej!

PangoSE, kan du till att börja med be SCB att uppdatera sin hemsida? För
närvarande står det visserligen att tätortsgeometrierna är öppna data [1]
men också att deras öppna data är CC-BY-licensierade [2] vilket inte är
tillräckligt för OSM [3]. Det är ingen bra idé att ladda upp data med oklar
licens.

Tätortsavgränsningarna ritas om från grunden vart tredje år. Vem tar ansvar
för att det hålls uppdaterat någon längre tid? Vi har fortfarande kvar mera
begränsade tätortsuppgifter som blev inaktuella 2015, t ex [4], och
eftersom ändringar i tätortsindelningen inte är direkt observerbara på
marken kan det dröja länge innan någon märker att något är fel, om det inte
kontrolleras systematiskt. Ett liknande fall är naturreservaten, som
importerades runt 2010. Jag har under en längre tid sysslat med att gå
igenom naturreservaten för att slå ihop överlappande gränser, och där finns
det många fall av gränsförändringar och nyskapade reservat som inte har
uppdaterats trots att naturreservaten har mer stabila gränser än tätorterna.

Tätortsavgränsningarna har ingen som helst administrativ funktion och det
är därmed direkt fel att tagga dem som boundary=administrative. Tätbebyggda
områden (som kommunerna använder för att avgränsa t ex 50-begränsningar och
tomgångskörningsförbud) har en viss administrativ funktion och är indirekt
observerbara på marken genom vägskyltar när man passerar deras gränser, men
det är en annan sak. Möjligtvis skulle boundary=census [5] fungera för
tätortsavgränsningarna, om de trots alla invändningar ska finnas i OSM.

Jag blir ännu mer skeptisk när jag ser hur tätortsavgränsningarna har lagts
in hittills, som i Malmö [6]. Relationen har note=Tätortsgränsen följer
inte LMs polygon slaviskt eftersom att denna inte täckte alla områden
ordentligt. Vad är överhuvudtaget meningen med att rita ut tätortsgränser
separat på OSM om det inte är de av SCB definierade tätorterna? Den
dataanvändare som vill använda OSM-data för att få en uppfattning om
bebyggda områden får ett bättre resultat av att aggregera urbana
markanvändningstyper som landuse=residential, industrial, retail etc, eller
i välmappade områden (som Malmö!) genom att analysera building=*.

Hälsningar
Essin


[1] https://www.scb.se/vara-tjanster/oppna-data/
[2] https://www.scb.se/vara-tjanster/oppna-data/oppna-geodata/tatorter/
[3] https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/
[4] https://www.openstreetmap.org/node/1779070277
[5] https://wiki.openstreetmap.org/wiki/Tag%3Aboundary%3Dcensus
[6] https://www.openstreetmap.org/relation/10663667

Den tors 23 jan. 2020 kl 14:39 skrev pangoSE :

> Hej.
>
> Jag tycker att vi skal tolka tätortsområden som administrativa gränser för
> våra städer. Det är den bästa källa vi har, alternativet är att göra dem
> subjektivt själva som jag ser det.
>
> Det är korrekt att dem uppdateras av SCB vart 5-e år. SCB har dock bara
> släppt dem som CC-BY varför jag föreslår att vi tar dem från LM. Jag ser
> inte det som ett problem att gränserna uppdateras när byn byggs ut eller
> stadsdelar rivs.
>
> Dem används inte bara av rendere också av tex
> https://maposmatic.osm-baustelle.de där det inte i dagsläget går att göra
> en karta över tex Malmö av skälet att staden inte är definerad som område.
>
> Se skillnaden när du söker här på härnösand vs malmö:
> https://maposmatic.osm-baustelle.de/new/#
>
> Vi saknar altså vettiga admin boundaries på våra städer. Alla svenska
> städer jag testade utom Härnösand och Umeå kunde inte lätt hittas.
>
> När man skapar bykartor då är det vettigt att bara ta med gatunamn inom
> byområdet och detta gör verktyget om vi har definerad gränserna.
>
> Jag skapade precis denna cykelkarta för Umeå med alla gatunamn i en bilaga
> där området utanför tätorten är grått och gator som ligger utanför
> byområdet inte tas med i indexet, se:
> https://maposmatic.osm-baustelle.de/maps/100341/qlPljYcLvFQNZKTI
> direktlänk till pdfen:
> https://maposmatic.osm-baustelle.de/results//100342_2020-01-23_14-30_umea.pdf
>
> mvh
>
> pangoSE
> On 2020-01-23 13:49, Andreas Vilén wrote:
>
> Tätortspolygoner ändras varje gång det görs en ny uppdatering, ett område
> byggs eller liknande. Det finns ingen etablerad taggning för detta och jag
> tror inte det är lämpligt att lägga in.
>
> Tätorter är inga administrativa enheter och har normalt inga gränser mer
> än rent statistiska.
>
> /Andreas
>
> Skickat från min iPhone
>
> 23 jan. 2020 kl. 13:18 skrev pangoSE :
>
> Hej
> Jag testade uMaps vektorkarta med outdoor lagret från thunderforest. (se
> https://umap.openstreetmap.fr/en/map/stugor-och-vindskydd_410556#7/55.835/13.964
> )
>
> På större zoom nivåer saknas städer i SE pga att dem endast är inritade
> som noder. tex
> https://nominatim.openstreetmap.org/details.php?place_id=133125
>
> I Danmark ser det mycket bättre ut...
>
> LM har släppt alla tätortspolygoner som CC0 så det är bara att importera.
> (Se geojson fil här https://www.mediafire.com/folder/dzngn1k5y2xjq/)
>
>
>
> 

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Hartmut Holzgraefe]

On 08.02.20 11:58, Rory McCann wrote:

On 07.02.20 20:12, stevea wrote:

A well-known example is (national, other) boundaries, which
frequently do not exist "on the ground,"

National borders don't exist on the ground? huh? Have you ever actually
_crossed_ an international border? I assure you they exist on the
ground. From large infrastructure, to changes in the paint colour on
roads, one can nearly always *see* where a border is.



might be easy to forget what borders can look like when being in a 
"Schengen"
country, especially if it is completely surrounded by other Schengen 
states. E.g. I once drove from Belgium to France by accident, and as it 
was in a very rural area it took a while until I finally noticed I had

missed some turn earlier on.

But even then, on the major roads it is hard to miss that you just 
entered a different country. You can't deduct the exact border line

by the centimeter by such observations, but you will usually be right
within less than a kilometer if you interpolate from those clearly
marked crossing points.

Disputed areas are usually much wider than that, and I'm pretty sure you
will notice when getting to what Russia thinks the current border line
is, and try to cross?




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

Re: [Talk-GB] Panorama Mapping Party with TrekView - May 23 - Ashurst, New Forest, UK

[Jez Nicholson]

Nice hookup with Trek Viewdoes this warrant adding to
https://wiki.openstreetmap.org/wiki/Current_events as a mapping party? I
always like seeing UK events on there.

On Fri, Feb 7, 2020 at 5:37 PM Nick Whitelegg 
wrote:

> Hello everyone,
>
> As some of you may know I am developing OpenTrailView (
> https://opentrailview.org), a pure 100% FOSS StreetView-like application
> for off-road routes such as hiking trails which uses OpenStreetMap data to
> auto-connect the panoramas together.
>
> Recently I've been working with Trek View (trekview.org), an organisation
> which aims to capture panoramas of the natural world.
> In their words: TrekView is a not-for-profit organisation using the power
> of panoramic photography to help educate and protect against further
> destruction of our beautiful planet. In 2020, they're launching Trekker
> Camp. Think virtual field trips. Trekker Camp will design and deliver
> immersive learning experiences to give students (7-11) the necessary
> understanding and skills to tackle the world's most pressing issues, from
> ocean health to climate change.
>
> TrekView loan 360 camera packs (using the GoPro Fusion) to allow people to
> capture imagery of the natural world, from off-road routes including hiking
> routes and rivers. As well as Google Street View, TrekView's software now
> allows contributors to upload to OpenTrailView.
>
> On to the most important aspect of this post. On May 23rd, and inspired by
> OSM mapping parties, we're organising a Panorama Mapping Party at Ashurst,
> New Forest, Hampshire, UK, with the aim of intensively capturing panoramic
> imagery of the paths and trails in the area which will then be uploaded to
> OpenTrailView. As OSM coverage in the area is exceptionally good, this
> should then result in the creation of extensive walk-through tours of the
> area.
>
> The form will be similar to mapping parties. The plan is to meet at 11:00
> (there's a train which arrives from London at the local station, Ashurst
> New Forest, at around 10:45), plan, capture imagery and then get together
> in the pub afterwards.
>
> More details (with OSM map showing location):
> https://www.trekview.org/blog/2020/pano-party-new-forest-uk-may-23-2020/
>
>
> So if you're interested in 360 photography and OSM, then do come along!
> 360 camera packs will be available to borrow and use on the day, or if you
> have your own device, please bring it along.
>
> Thanks,
> Nick
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] Crimea situation - on the ground

[Rory McCann]

On 08.02.20 12:01, Colin Smale wrote:
Absolutely. But we should document our sources! Basic rule of research. 
And if we choose to promote one alternative above the others, we are 
skating on thin ice.


IMO, the "alternative" OSM promotes is "what's on the ground". Let's 
nail our colours to the mast. IMO this is our (long standing) standard. 
In theory, we don't need to provide documentation, because, in theory, 
other mappers can "go there" and "look" at it first hand themselves.


Have we actually asked the people of Crimea 
first-hand what they think? No=>it's someones opinion.


My example of "asking people on the ground" is for city names. 
`admin_level=2` border (IMO) means (except here) "what country 
physically controls the area".


Is there anyone who actually doesn't think Russia currently _does_ 
control the area? Anyone in Crimea, in Ukraine, in Russia, who doesn't 
think that? I don't think so. (whether you think Russia _should_ control 
it or not). I suspect Ukrainian police don't go into Crimea today, 
showing a certain level of knowledge of who actually controls the area 
now


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

Re: [OSM-talk] Crimea situation - on the ground

[Hartmut Holzgraefe]

On 07.02.20 20:56, Colin Smale wrote:

In the case of Crimea, two different authorities have different views of 
the jurisdiction to which it belongs. That is a fact, that we can safely 
map. We can represent the border in one place "according to Russia" and 
in another place "according to Ukraine" without taking sides. 


for the political borders we can simply provide both views. But that 
still ignores the "on the ground" fact that you may have a much harder

time trying to pass one of these border versions than the other ...


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

Re: [OSM-talk-fr] Demande d'intervention de tiers sur un conflit d'édition

[Charles MILLET]

Merci pour les conseils :)

On 07/02/2020 22:17, Jérôme Seigneuret wrote:

Dans ton cas de toute-façon il y a une signalisation verticale...
Ca reste de la dégradation sans justification.
Après discussion propose lui déjà de faire un revert de son changeset 
en mettant les liens et notre discussion mail.


Si c'est pas fait tu le fais et si des modifications reviennent sans 
justification tu pourras ouvrir une demande de gestion des conflits 
auprès du DWG https://wiki.openstreetmap.org/wiki/Disputes



Le ven. 7 févr. 2020 à 21:29, Charles MILLET > a écrit :


Merci Florimond pour ton retour. Il y a bien une ligne de
séparation qui est déjà bien effacée.

En fait je craque avec ce contributeur, il efface très
régulièrement des trucs juste parce que ça lui plaît pas et pas
mal de piste cyclables que des débutants OSM prennent le temps de
mapper pour les remplacer par du track même quand c'est même plus
justifiable pour du routage.

On 07/02/2020 20:30, Florimond Berthoux wrote:

Salut,

Merci pour le lien mapillary,

highway=path
bicycle=designated
foot=designated
seggregated=? (j'ai l'impression qu'il y a une ligne de démarcation)

sur le way de la route tu peux ajouter
bicycle=use_sidepath

cycleway:right=track me semble peu pertinent ici étant donné que
piétons et cyclistes sont mélangés sur la même chaussée.

Des fois c'est peut-être plus simple d'attendre et de changer
sans discuter.. ;)


Le ven. 7 févr. 2020 à 16:12, Jérôme Seigneuret
mailto:jerome.seigneu...@gmail.com>> a écrit :


https://www.mapillary.com/map/im/ZF99wjAm9RtiGhd-LmrDMw


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

Après mettre highway=footway + bicycle=designated ou
highway=cycleway + foot=designated ... pour moi c'est du
débat idéologique. Ca reste de base un trottoir donc fait
pour les piétons avec une obligation pour les vélos d'y
circuler...
Au niveau exploitation des données d'y voit pas de différence.




Le ven. 7 févr. 2020 à 16:04, Jérôme Seigneuret
mailto:jerome.seigneu...@gmail.com>> a écrit :

marc il y a un lien mapilary

Pour moi c'est bien un Cycleway séparé de la voie sur un
trottoir avec accès piéton et ségrégation clairement
affiché sur panneau.
Il faut mettre une la voie routière cycleway=use_sidepath
car c'est une obligation de circuler sur le trottoir

Bonne journée

Le ven. 7 févr. 2020 à 16:02, marc marc
mailto:marc_marc_...@hotmail.com>> a écrit :

Le 07.02.20 à 15:49, Charles MILLET a écrit :
> Pour info cette "piste cyclable" est utilisable par
les piétons et donc
> nécessite un way séparé et la précision du
segregated=yes

il y a une erreur dans l'argument ?
photo classique récente du lieu ou uniquement vue sat ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org

https://lists.openstreetmap.org/listinfo/talk-fr



-- 
Cordialement,

Jérôme Seigneuret



-- 
Cordialement,

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



-- 
Florimond Berthoux


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

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



--
Cordialement,
Jérôme Seigneuret

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

[OSM-talk] OSM/LondonOSM | Re: Crimea situation - on the ground

[Rory McCann]

On 07.02.20 20:22, Yuri Astrakhan wrote:

(e.g. two fairly large groups of people could refer to the same
place/object by different names). ... the map should be able to
reflect difference of opinions to some "reasonable" degree (an
intentionally vague term).
One useful example of that is a city in the north west of the island of 
Ireland, called (in English) either Derry or Londonderry. Everyone 
agrees on the Irish name (`name:ga`) (
gaDoire
). OSM's 
multilingual tagging scheme, but for dialects, are used to differentiate 
the Hiberno-English (en_IE) name (
en-IEDerry
) from the 
British-English (en_GB) term (
en-GBLondonderry
). The `name` 
tag uses the commonly used compromise. That approach could work for 
other areas.


RFC 1766 (for IETF language tags) appears to allow quite detailed 
specification of languages & areas, and could be useful.


https://www.openstreetmap.org/node/267762522
https://tools.ietf.org/html/rfc1766
https://en.wikipedia.org/wiki/IETF_language_tag

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

Re: [OSM-talk] Crimea situation - on the ground

[Colin Smale]

On 2020-02-08 11:48, Rory McCann wrote:

> It is true that government A might have one opinion, and government B might 
> have another, and Provisional Autonomous Republic of C might have another 
> opinion.
> 
> But there can be another way. We go there, and we see what nearly everyone 
> there calls it. We look at the words on the signs. We look at the name of the 
> organisations based there ("Transport for London"). We walk down the street 
> and ask 100 people what the name of this city is. We listen into 
> conversations there, and see if there's a majority name that people use when 
> they talk to each other about the city
> 
> And the answer to that is "London".
> 
> In OSM, we could tag that "the opinion of the UK government is that this city 
> is called London", and "the opinion of the French government is that this 
> this city is called Londres", and "the commonly used name for this city by 
> the vast majority of people who live there is London".
> 
> We should map the third option with the `name` tag.

Absolutely. But we should document our sources! Basic rule of research.
And if we choose to promote one alternative above the others, we are
skating on thin ice. Have we actually asked the people of Crimea
first-hand what they think? No=>it's someones opinion. Can we base our
choice on someone else's research? Which research is that? No=>it's
someone's opinion. Unless we can point to it being "in someone else's
opinion", we must take responsibility for our own conclusions. If that's
too hard, better to not have an opinion i.e. don't promote anything as
"more equal than others".___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Rory McCann]

On 07.02.20 20:12, stevea wrote:

A well-known example is (national, other) boundaries, which
frequently do not exist "on the ground,"

National borders don't exist on the ground? huh? Have you ever actually
_crossed_ an international border? I assure you they exist on the
ground. From large infrastructure, to changes in the paint colour on
roads, one can nearly always *see* where a border is.


Other examples include large bodies of water and mountain ranges.
I've lived on the Pacific coast most of my life and been to dozens of
beaches, but never once on any beach have I seen a sign which reads
"Pacific Ocean."  Same with no signs at the edge of or in the middle
of "Rocky Mountains" or "The Alps."  (I've been, and I haven't seen).
Yet, OSM maps oceans and mountain ranges.  How do we know their names
without anything on the ground?
We ask people there. We look at books, at maps, at whether there is a 
detailed Wikipedia article on the topic, do are travel books published 
that refer to this area as that, do organisations that cover that area 
use that term. We look to see if the name is _used in reality_.


That's the "on the ground rule". IMO "on the ground" refers to 
"observable reality".


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

Re: [OSM-talk] Crimea situation - on the ground

[Rory McCann]

It is true that government A might have one opinion, and government B 
might have another, and Provisional Autonomous Republic of C might have 
another opinion.


But there can be another way. We go there, and we see what nearly 
everyone there calls it. We look at the words on the signs. We look at 
the name of the organisations based there (“Transport for London”). We 
walk down the street and ask 100 people what the name of this city is. 
We listen into conversations there, and see if there's a majority name 
that people use when they talk to each other about the city


And the answer to that is “London”.

In OSM, we could tag that "the opinion of the UK government is that this 
city is called London", and "the opinion of the French government is 
that this this city is called Londres", and "the commonly used name for 
this city by the vast majority of people who live there is London".


We should map the third option with the `name` tag.

On 07.02.20 20:56, Colin Smale wrote:
Many things we think of as "facts" are in fact somewhat subjective. 
Things have a name or some attribute "according to" some authority. 
London "is not" London, it is "called" London according to local people, 
government etc. But the same place is "called" Londres, according to a 
different authority, namely French-speakers; both points of view are 
equally valid, but only within their intended context.


In the case of Crimea, two different authorities have different views of 
the jurisdiction to which it belongs. That is a fact, that we can safely 
map. We can represent the border in one place "according to Russia" and 
in another place "according to Ukraine" without taking sides. It is then 
down to the renderer/consumer which source is preferred. If we don't 
stop taking sides, well, we are taking sides - whatever our arguments to 
support our choice. We will never "win" that one.


I am applying a bit of data management here; every data item should have 
a provenance, value domain, validity period etc. The "truth" is always 
only relative to a particular frame of reference.


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

[talk-cz] 18. pravidelný olomoucký mapathon

[Antonin Haas]

Ahoj,
19.2.2020 se koná další olomoucký mapathon. Start je v 18h tradičně v 
učebně LP2.004 na adrese Přírodovědecká fakulta Univerzity Palackého v 
Olomouci, 17. listopadu 12, 77146 Olomouc, Czech Republic

S sebou vlastní notebook a ideálně také myš.
odkaz na FB událost https://www.facebook.com/events/796659510832071/

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

Re: [OSM-talk-fr] stabilité et stat sur la disponibilité du fond OSM org

[osm . sanspourriel]

Le 08/02/2020 à 09:35, Christian Quest - cqu...@openstreetmap.fr a écrit :


Le 07/02/2020 à 23:12, Jérôme Seigneuret a écrit :

Je suis déjà parti sur le principe de proposer du Mapbox ou une
solution interne.


Penses au français aussi... Mapbox commence a être envahissant et les
positions dominantes c'est jamais sain.


Ou allemand. Outre ce que dit Christian il y a aussi la question du
prix. Mais c'est aussi le reflet d'une position dominante.


Oui, c'est sûr que si un fond Google te va, tu te fiches un peu de ce
qu'il y a sur le fond de carte !

Beaucoup de choses incomplètes, obsolètes, et surtout pas neutre du
tout dans le choix de POI (publicitaires).


+1, c'est ainsi qu'en lisant la page contact d'un fabricant de cheminées
je voyais essentiellement la pub d'un vendeur de cheminées.

Sinon ce serait bien qu'OsmAnd mettre a dispo un petit serveur XYZ (ou
TMS...) afin de pouvoir utiliser la carto OsmAnd sur un mobile : absence
de besoin de connexion internet. Une idée pour un hackathon ?

Au fait, le problème de dispo de carte sur mobile ne vient-il pas
essentiellement du lien internet ? Je ne sais dans quel contexte tu
comptes travailler.

N. B. : j'ai par le passé étudié différentes solutions allant du serveur
maison sans connexion internet à la solution cloud, on peut échanger en
MP si tu veux.

> De toute-façon l'étude de coût GM n'est pas évaluée car compliqué à
estimer par le prestataire...
Quand c'est flou il y a un loup."juste"
25 000 $ / an dans notre cas (alors que sur un logiciel similaire on
utilisait de la tuile de nos serveurs - avec aussi de la possibilité de
tuile OSM). Comme le serveur de carto c'était la machine de secours de
l'appli on avait un coût du serveur de carte de 0 €/an.

Si c'est 'juste" pour un fond de carte, pourquoi ne pas aller vers des
fonds style Stamen Toner
 ?

Sans oublier le ©, attention ces services gratuits ont en général une
durée de vie limitée, le temps de faire connaître l'entreprise, voir à
ce sujet l'évolution de MapQuest (ou de Google Maps) : ça disparaît,
devient payant ou les utilisations possibles deviennent de plus en plus
restrictives, les logos deviennent envahissants (un par tuile !)... ou
ça continue !

Ou exploiter le mtile que Christian produit (zoom maxi 10) et ajouter un
autre pour les niveaux plus élevés par sur une zone plus restreinte. Bon
visiblement si votre prestataire propose du GM c'est mal barré.

Jean-Yvon

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

Re: [OSM-talk-fr] stabilité et stat sur la disponibilité du fond OSM org

[Christian Quest]

Le 07/02/2020 à 23:12, Jérôme Seigneuret a écrit :
Je suis déjà parti sur le principe de proposer du Mapbox ou une 
solution interne.


Penses au français aussi... Mapbox commence a être envahissant et les 
positions dominantes c'est jamais sain.



@Vincent la question de garantie n'est pas abordée. Aujourd'hui toute 
les apli basé sur du Leaflet et de l'Openlayer mettent par defaut OSM 
en basemaps. Esri propose la couche en Lyr et elle est exploitable et 
proposé par défaut dans QGIS... Faut regarder ce qu'il se passe au 
réel. Maintenant c'est pas mon objectif de saturer un service. De 
toutefaçon la partie tech bloquera le service trop consommateur si 
c'est le cas ou me rapellera à l'ordre.


Je me fou de la garantie et j'ai pas abordé cette partie. Ce que je 
cherche c'est à comparer la disponibilité d'un service osm.org 
 vu que c'est ce qui est comparé aujourd'hui et non 
son actualisation. Je pense que les mecs ne savent même pas comment 
une basemap est mise à jour. Ils consomment juste le service pour 
avoir un rendu.


Oui, c'est sûr que si un fond Google te va, tu te fiches un peu de ce 
qu'il y a sur le fond de carte !


Beaucoup de choses incomplètes, obsolètes, et surtout pas neutre du tout 
dans le choix de POI (publicitaires).



Si je veux une garantie je prends un fournisseur pour éviter ou 
limiter une rupture de service. L'objectif c'est de péter un argument 
sans fondement pour dire qu'on veut pas du modèle opensource...
Sachant que la mise à jour de l'api interne à des coupures de service 
bien plus récurrente que ne peut l'avoir le fond OSM . d'où peut-être 
des stat munin...



Les stats munin ne sont pas assez fines pour avoir un taux de dispo.

Notre cache à Lyon (FR + HOT), a un taux de dispo de 100% d'après 
uptimerobot... pas de coupure depuis le 4 juillet 2019.


--
Christian Quest - OpenStreetMap France

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