[OSM-talk-fr] Validateur JOSM : "Valeur de la propriété inconnue"

[Yves P.]

Bonjour,

Je n’arrive pas à trouver le validateur de JOSM pour faire un ticket approprié.
(vivement Github ou Gitlab )

Il trouve des tags "man_made=grave" et suggère que la valeur serait « crane » 

D’après le wiki, c’est "cemetery=grave ».

Il y en a 418  d’après 
taginfo.

On corrige la règle ou on nettoie ça à la main ?

—
Yves





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

Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?

[Michael Collinson]

I suggest this is "referencing" and, while it does not mention the word, 
is covered in the Legal FAQ 
https://wiki.osmfoundation.org/wiki/Licence/Licence_and_Legal_FAQ#Can_I_use_OSM_data_and_OpenStreetMap-derived_maps_to_verify_my_own_data_without_triggering_share-alike.3F


I think I originally wrote this. Perhaps the LWG would consider if there 
is reasonable consensus and add machine data training as a third example.


Here is a thought experiment to test it:

1) If you notice something interesting in Google Streetview or on an 
in-copyright map and copy it into OpenStreetMap, that is a no-no.  But 
if you go to the location and verify it for yourself, perhaps taking 
your own photos, that is OK. You have used the third-party resources as 
a reference. However, you have then done your own original research and 
based your OpenStreetMap contribution on that.


2) Several years ago, the South African government mapping directorate, 
(who have been very friendly and cooperative with us), wanted to monitor 
OSM for changes, perhaps using machine algorithms. They could then send 
a mapping resources to just those places and remap them. This saves 
enormous amounts of budget in frequently resurveying the entire country 
or large parts of it. Was that OK given that not all their re-survey 
might find its way into open data sets? The LWG at time considered this 
was OK, because of the referencing principle that, while it 
"helped/aided/assisted", it did not involve copying/extracting our data.


3) So, I suggest that it is a logical extension that machine data 
training (and perhaps back testing too?) certainly "helps/aids/assists" 
but does NOT involve  copying our data - then it is referencing rather 
than deriving. As one early thread responder suggested, this is a grey 
area. But my strong feeling is that a liberal rather than restrictive 
interpretation is more helpful to us in growing or map and user base 
than not.


Mike


On 2019-11-15 10:29, stevea wrote:

I don't know.  I've expressed my opinion(s) on the matter, and believe the LWG should 
chime in with "an" (the?) answer.

SteveA
California


On Nov 14, 2019, at 3:27 PM, Martin Koppenhoefer  wrote:
sent from a phone


On 15. Nov 2019, at 00:19, stevea  wrote:

But the "ultimate test" of "can the new work be made without OSM data?" remains a good 
one, in my opinion, because then, the author can be told, "well, then, go do so, please, otherwise offer 
us attribution of some sort" (whether legally required, or not).


if you distribute a dataset and say: all roads but not those in OpenStreetMap, 
isn’t this already attribution? The question is whether you’d want to force 
them to distribute under ODbL rather than MIT (and maybe what the downstream 
users have to attribute).

Cheers Martin


___
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] Licence of Facebook's derived road datasets? ODbL?

[Kathleen Lu via talk]

IMO (not yet stating the official opinion of the LWG since the LWG has not
had time convene and discuss), the predicted roads are not a Derivative
Database and Facebook can apply whatever license it wants to them
(including MIT).

It is not a case of “raw data dervived from aerial imagery, plus OSM data”,
it is a case of “raw data dervived from aerial imagery, *minus* OSM data”.
That makes a key difference, as others have pointed out, the law protects
copying or extracting a substantial part of a protected database. Simply
using a database does not make something a Derivative Database. (And the
ODbL does not prohibit things the law allows.)

Christoph mentioned an example from the Horizontal Map Layers Guideline:
"You add a non-OpenStreetMap cemetery layer that is defined as 'all
cemeteries not found in the OpenStreetMap data layers'."
The key context here is *add*, as in, add to an OSM database. In this
Facebook example, when Facebook releases its detected roads, those are
*not* added to an OSM database.
He also mentioned tan example from the Collective Database Guideline which
expresses the same sentiment in clearer language:
"You have a proprietary list of restaurants for a country. You would like
to complement your list with the corresponding data from OpenStreetMap
removing any duplicate objects in the process. The resulting, combined
database would not be covered by this guideline and you would, if the
dataset is publicly used, have to consider that your proprietary data may
be subject to the ODbL share-alike terms."
The "resulting, combined database" is the one that would not be considered
a Collective Database. Nothing in the Guidelines suggests that the
*uncombined* data could be a Derivative Database.

(As a side note, Martin, the Geocoding Guidelines do *not* say that
Geocoding Results are Produced Works: "Individual Geocoding Results are
insubstantial database extracts:"... "If Geocoding Results are used to
create a new database that contains the whole or a substantial part of the
contents of the OSM database, this new database would be considered a
Derivative Database")

-Kathleen

On Thu, Nov 14, 2019 at 4:37 PM Yuri Astrakhan 
wrote:

> Stevea, I think this discussion mixes two topics, as Martin pointed out:
> * I want to be credited for my work (i.e. you couldn't have done it
> without me, just say so)
> * I want to control what you do with the results of my work (i.e. you must
> not kill baby seals using the map I created)
>
> The first one is mostly a social construct, and most of the time we are ok
> if someone just says "came from OSM" - because then we know others will
> want to find out more, and join the project, growing the community, and
> essentially giving back to what you believe in. E.g. if i donate $5 to the
> grow a tree (Arbor Day) foundation, my money is mostly useless unless you
> also donate to them.
>
> The second is different. It's a legal weapon, something we can use when
> our sole existence is at stake. We will have to spend money and time
> defending it. When OSM started, some people didn't want Google to benefit
> from the volunteer efforts without giving back (see point #1). So they went
> into all sorts of legal mambo jumbo to prevent such unholy use.  They were
> successful - Google hasn't used the data directly.  It would be very hard
> to say if this did more damage than good to the OSM project itself (rather
> than if we used CC0 license), but it has been done.
>
> Yet, forcing public domain data to be distributed under a more restrictive
> license just because we want to be nitpicky about the letter of the license
> achieves neither of the above goals.  Rather, it scares users away.  I
> seriously doubt of the validity of this legal theory, but even if it is
> correct, it is not in OSMs best interest to pursue such restriction. It
> does not gain us anything, and causes a lot of collateral PR damage in the
> process.
>
> On Thu, Nov 14, 2019 at 6:29 PM stevea  wrote:
>
>> I don't know.  I've expressed my opinion(s) on the matter, and believe
>> the LWG should chime in with "an" (the?) answer.
>>
>> SteveA
>> California
>>
>> > On Nov 14, 2019, at 3:27 PM, Martin Koppenhoefer <
>> dieterdre...@gmail.com> wrote:
>> > sent from a phone
>> >
>> >> On 15. Nov 2019, at 00:19, stevea  wrote:
>> >>
>> >> But the "ultimate test" of "can the new work be made without OSM
>> data?" remains a good one, in my opinion, because then, the author can be
>> told, "well, then, go do so, please, otherwise offer us attribution of some
>> sort" (whether legally required, or not).
>> >
>> >
>> > if you distribute a dataset and say: all roads but not those in
>> OpenStreetMap, isn’t this already attribution? The question is whether
>> you’d want to force them to distribute under ODbL rather than MIT (and
>> maybe what the downstream users have to attribute).
>> >
>> > Cheers Martin
>>
>> ___
> talk mailing list
> talk@openstreetmap.org
> 

Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?

[Yuri Astrakhan]

Stevea, I think this discussion mixes two topics, as Martin pointed out:
* I want to be credited for my work (i.e. you couldn't have done it without
me, just say so)
* I want to control what you do with the results of my work (i.e. you must
not kill baby seals using the map I created)

The first one is mostly a social construct, and most of the time we are ok
if someone just says "came from OSM" - because then we know others will
want to find out more, and join the project, growing the community, and
essentially giving back to what you believe in. E.g. if i donate $5 to the
grow a tree (Arbor Day) foundation, my money is mostly useless unless you
also donate to them.

The second is different. It's a legal weapon, something we can use when our
sole existence is at stake. We will have to spend money and time defending
it. When OSM started, some people didn't want Google to benefit from the
volunteer efforts without giving back (see point #1). So they went into all
sorts of legal mambo jumbo to prevent such unholy use.  They were
successful - Google hasn't used the data directly.  It would be very hard
to say if this did more damage than good to the OSM project itself (rather
than if we used CC0 license), but it has been done.

Yet, forcing public domain data to be distributed under a more restrictive
license just because we want to be nitpicky about the letter of the license
achieves neither of the above goals.  Rather, it scares users away.  I
seriously doubt of the validity of this legal theory, but even if it is
correct, it is not in OSMs best interest to pursue such restriction. It
does not gain us anything, and causes a lot of collateral PR damage in the
process.

On Thu, Nov 14, 2019 at 6:29 PM stevea  wrote:

> I don't know.  I've expressed my opinion(s) on the matter, and believe the
> LWG should chime in with "an" (the?) answer.
>
> SteveA
> California
>
> > On Nov 14, 2019, at 3:27 PM, Martin Koppenhoefer 
> wrote:
> > sent from a phone
> >
> >> On 15. Nov 2019, at 00:19, stevea  wrote:
> >>
> >> But the "ultimate test" of "can the new work be made without OSM data?"
> remains a good one, in my opinion, because then, the author can be told,
> "well, then, go do so, please, otherwise offer us attribution of some sort"
> (whether legally required, or not).
> >
> >
> > if you distribute a dataset and say: all roads but not those in
> OpenStreetMap, isn’t this already attribution? The question is whether
> you’d want to force them to distribute under ODbL rather than MIT (and
> maybe what the downstream users have to attribute).
> >
> > Cheers Martin
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] iD editor

[Lorenzo Mastrogiacomi]

Il giorno mer, 13/11/2019 alle 20.42 +0100, Martin Koppenhoefer ha
scritto:
> 
> Scusate, tanto testo ;-)
> 
> Che dite, vogliamo appoggiare l'idea? Attualmente è ancora molto
> "fresco" (da modificare, è la prima bozza), ma la direzione sarà
> probabilmente quella, attualmente c'è la discussione in talk-de e
> forum.
> 
> Ciao
> Martin
> 
> 
> ___

Iniziativa giusta e che aspettavo da un pezzo. Voterò a favore.


Grazie
Lorenzo


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

Re: [Talk-de] Windy Map mißachtet OSM-Lizenz?

[Robert Grübler]

Am 15. November 2019 00:22 schrieb Martin Koppenhoefer 
[mailto:dieterdre...@gmail.com]
<
< Das läuft schon seit 2016 so? 
https://community.windy.com/topic/3353/map-correction/11 
mitteilen?

LG Robert


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

Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?

[stevea]

I don't know.  I've expressed my opinion(s) on the matter, and believe the LWG 
should chime in with "an" (the?) answer.

SteveA
California

> On Nov 14, 2019, at 3:27 PM, Martin Koppenhoefer  
> wrote:
> sent from a phone
> 
>> On 15. Nov 2019, at 00:19, stevea  wrote:
>> 
>> But the "ultimate test" of "can the new work be made without OSM data?" 
>> remains a good one, in my opinion, because then, the author can be told, 
>> "well, then, go do so, please, otherwise offer us attribution of some sort" 
>> (whether legally required, or not).
> 
> 
> if you distribute a dataset and say: all roads but not those in 
> OpenStreetMap, isn’t this already attribution? The question is whether you’d 
> want to force them to distribute under ODbL rather than MIT (and maybe what 
> the downstream users have to attribute).
> 
> Cheers Martin


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

Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?

[Martin Koppenhoefer]

sent from a phone

> On 15. Nov 2019, at 00:19, stevea  wrote:
> 
>  But the "ultimate test" of "can the new work be made without OSM data?" 
> remains a good one, in my opinion, because then, the author can be told, 
> "well, then, go do so, please, otherwise offer us attribution of some sort" 
> (whether legally required, or not).


if you distribute a dataset and say: all roads but not those in OpenStreetMap, 
isn’t this already attribution? The question is whether you’d want to force 
them to distribute under ODbL rather than MIT (and maybe what the downstream 
users have to attribute).

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

Re: [Talk-de] Windy Map mißachtet OSM-Lizenz?

[Martin Koppenhoefer]

sent from a phone

> On 15. Nov 2019, at 00:16, Robert Grübler  wrote:
> 
> Since you have been informed about lapses in this since 2016, 
>   yourselves.


Das läuft schon seit 2016 so? Mit DCMA ist es eine Sache von wenigen Tagen oder 
gar Stunden.

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

Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?

[stevea]

Yuri, I appreciate your analogies and making the point about "derived."  Yes, 
we are inspired by architecture we see, if we incorporate a little finial from 
a public building in our new roof project, do we owe the architecture money, or 
a nod?

There are plenty of examples like this in real life, we all "stand on each 
other's shoulders" to some extent in everything we do, whether it is a language 
/ culture we share, or identifiable elements that somebody might point to and 
say "well,  clearly, here is a case of 'imitation is the sincerest form of 
flattery,' as clearly you were inspired by another work."  That happens, I 
realize, it is part of the human endeavor.

I'm making the point (especially as I say "inspiration") that if OSM data 
"inspire" the new work, it might be derived.  It is certainly "inspired," but 
it might not legally be derived.  Once again, I don't know where to draw the 
legal line, but I do have an opinion that if new works cannot be made without 
OSM, some attribution should be made to OSM.  Maybe legally yes, attribution is 
required, maybe legally, no, it isn't.  But the "ultimate test" of "can the new 
work be made without OSM data?" remains a good one, in my opinion, because 
then, the author can be told, "well, then, go do so, please, otherwise offer us 
attribution of some sort" (whether legally required, or not).

These are ultimately questions for the Legal Working Group, however, I do hope 
they are inspired by the strong feelings and opinions of OSM volunteers about 
our data / works.

SteveA
California

> On Nov 14, 2019, at 3:09 PM, Yuri Astrakhan  wrote:
> 
> stevea, I would not be exactly the same person without OSM. Does it mean ODbL 
> applies to me?  A hammer was used to build a house, but the house does not 
> have hammer's copyright. Just because some data was used in the process does 
> not necessarily mean that whoever saw that data taints everything they touch 
> from thereon with ODbL license. In some cases it does, like when portions of 
> OSM data make it into the final product, but I seriously doubt that if 
> someone computes average time OSM editors contribute to the OSM project, and 
> publishes that average, and afterwards someone else publishes how often 
> someone publishes papers about OSM community, they must use ODbL license... 
> Even though that last research paper would not be possible without the first 
> research paper, which would not be possible without OSM data.

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

Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?

[Martin Koppenhoefer]

even if we would have a right to be quoted for the absent data, IMHO it would 
be silly to pursue the case.
I‘d rather spend the resources on those cases where they are actually using 
OpenStreetMap data and not sufficiently attributing it. There’s a lot of cases, 
Facebook being one of them.

I also find it strange that the geocoding guideline sees geocoding results as 
produced works, but then waives the attribution requirement for their use (only 
the geocoder must attribute, the results seem to be free of any attribution 
requirements)
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Geocoding_-_Guideline


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

Re: [Talk-de] Windy Map mißachtet OSM-Lizenz?

[Robert Grübler]

Am : Donnerstag, 14. November 2019 23:09 schrieb Martin Koppenhoefer 
[mailto:dieterdre...@gmail.com]

< Ich meinte ob Du Windy kontaktiert hast, 
< vielleicht haben sie das mit der Lizenz ja nur übersehen o_O

Am Donnerstag, 14. November 2019 22:23 schrieb streckenkundler 
[mailto:o...@die-spreewaldbahn.de]
< ja, es fehlt der Lizenzhinweis... 
https://community.windy.com/topic/3353/map-correction/12
Ebendort wurde der erste Hinweis auf die Lizenzverletzung am 14. Dez. 2016 
gepostet

Weitere Kontaktaufnahmen sind in der Tabelle von
https://wiki.openstreetmap.org/wiki/Lacking_proper_attribution
in der Spalte " www.windyty.com " dokumentiert.

Leider ist diese Tabelle sehr unübersichtlich. Die Windy Map ist 2x eingetragen 
einmal als "fixed" und einmal als not ok. Der letztere Eintrag stammt von mir. 
Hier ist die erste Kontaktaufnahme mit 2016-08-25 datiert.
Wie sich das "fixed" begründet ist unklar. Das zeigt die Schwäche dieser 
Tabelle. Es fehlt an Nachweisen.

Zitat Post drhayes:
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?

[Yuri Astrakhan]

stevea, I would not be exactly the same person without OSM. Does it mean
ODbL applies to me?  A hammer was used to build a house, but the house does
not have hammer's copyright. Just because some data was used in the process
does not necessarily mean that whoever saw that data taints everything they
touch from thereon with ODbL license. In some cases it does, like when
portions of OSM data make it into the final product, but I seriously doubt
that if someone computes average time OSM editors contribute to the OSM
project, and publishes that average, and afterwards someone else publishes
how often someone publishes papers about OSM community, they must use ODbL
license... Even though that last research paper would not be possible
without the first research paper, which would not be possible without OSM
data.

On Thu, Nov 14, 2019 at 5:53 PM stevea  wrote:

> While exactly "the data" may not be "in" the derived work, because of the
> process of their creation, "their spirit" are in the derived work, as they
> were a part of the new data's production.  That strongly seems "derived" to
> me, whether that "spirit" is inspirational or gives rise to "do include
> this, don't include that."  These decisions are based upon OSM data, so OSM
> is being "derived" to make the new work.
>
> Again, if the data aren't derived from OSM, please create them exactly the
> same withOUT OSM data and "then we shall see" (whether OSM data are
> necessary or optional for the new work's duplicate creation).  If you can
> do that without OSM data, please do so.  If you MUST use OSM data (even if
> no actual OSM data end up in the final work), then please agree that the
> final work is at least partly derived from OSM data.
>
> This doesn't seem that difficult to do on a verbal level, though again,
> I'm not sure of how it holds up legally.
>
> SteveA
> California
>
> > On Nov 14, 2019, at 2:45 PM, Martin Koppenhoefer 
> wrote:
> > I guess the law often doesn’t work like common sense. ODbL says it
> protects the database or a substantial extract of it. Where’s the data from
> OSM in this dataset?
> >
> > Cheers Martin
>
> >> On 14. Nov 2019, at 23:25, stevea  wrote:
> >>
> >> But if you DO use that "OSM over-layer," then please:  agree with
> common sense that those work are derived from OSM, even if they do not
> contain OSM data in them.  They contain data "helped" by OSM data, so they
> are derived (I would argue).
>
>
> ___
> 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] Licence of Facebook's derived road datasets? ODbL?

[stevea]

While exactly "the data" may not be "in" the derived work, because of the 
process of their creation, "their spirit" are in the derived work, as they were 
a part of the new data's production.  That strongly seems "derived" to me, 
whether that "spirit" is inspirational or gives rise to "do include this, don't 
include that."  These decisions are based upon OSM data, so OSM is being 
"derived" to make the new work.

Again, if the data aren't derived from OSM, please create them exactly the same 
withOUT OSM data and "then we shall see" (whether OSM data are necessary or 
optional for the new work's duplicate creation).  If you can do that without 
OSM data, please do so.  If you MUST use OSM data (even if no actual OSM data 
end up in the final work), then please agree that the final work is at least 
partly derived from OSM data.

This doesn't seem that difficult to do on a verbal level, though again, I'm not 
sure of how it holds up legally.

SteveA
California

> On Nov 14, 2019, at 2:45 PM, Martin Koppenhoefer  
> wrote:
> I guess the law often doesn’t work like common sense. ODbL says it protects 
> the database or a substantial extract of it. Where’s the data from OSM in 
> this dataset?
> 
> Cheers Martin 

>> On 14. Nov 2019, at 23:25, stevea  wrote:
>> 
>> But if you DO use that "OSM over-layer," then please:  agree with common 
>> sense that those work are derived from OSM, even if they do not contain OSM 
>> data in them.  They contain data "helped" by OSM data, so they are derived 
>> (I would argue).


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

Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?

[Martin Koppenhoefer]

sent from a phone

> On 14. Nov 2019, at 23:25, stevea  wrote:
> 
> But if you DO use that "OSM over-layer," then please:  agree with common 
> sense that those work are derived from OSM, even if they do not contain OSM 
> data in them.  They contain data "helped" by OSM data, so they are derived (I 
> would argue).


I guess the law often doesn’t work like common sense. ODbL says it protects the 
database or a substantial extract of it. Where’s the data from OSM in this 
dataset?

Cheers Martin 




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

Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?

[stevea]

I'm not an attorney, but I do have an opinion.  Just because there "is no data 
from OSM in the dataset" does not mean they are (or aren't) derived.  If OSM 
data were used in conjunction with its production, I think an argument can be 
made that those work are derived.  The question would be:  "can these data be 
created exactly as they are WITHOUT any OSM data (used as an over-layer, for 
example)?"  If so, OK, then "don't do that" and create them that way and there 
isn't any question.  But if you DO use that "OSM over-layer," then please:  
agree with common sense that those work are derived from OSM, even if they do 
not contain OSM data in them.  They contain data "helped" by OSM data, so they 
are derived (I would argue).

SteveA
California

> On Nov 14, 2019, at 2:19 PM, Martin Koppenhoefer  
> wrote:
> 
> I would believe it isn’t a derived work, as there is no data from 
> OpenStreetMap in the dataset.
> 
> I agree with Mateusz, if they trained their ai with OpenStreetMap data, you 
> could take the position that every outcome of their blackbox is 
> OpenStreetMap-derived, but AFAIK it is a gray area.
> 
> 
> Ciao Martin


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

Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?

[Martin Koppenhoefer]

I would believe it isn’t a derived work, as there is no data from OpenStreetMap 
in the dataset.

I agree with Mateusz, if they trained their ai with OpenStreetMap data, you 
could take the position that every outcome of their blackbox is 
OpenStreetMap-derived, but AFAIK it is a gray area.


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

Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?

[Wayne Emerson, Jr. via talk]

There seems to be a misunderstanding of the definition of "Derived". In 
order for something to be considered derived it needs to contain some 
elements from which it was derived. The end product described by 
facebook contains no OSM data, therefore it is literally the opposite of 
a derived product.


As far as licensing I can't comment on that.

On 11/14/2019 4:50 PM, Mateusz Konieczny wrote:




14 Nov 2019, 22:12 by yuriastrak...@gmail.com:

Let me get this straight:

* I create a dataset from public data sources, e.g a list of
roads, and publish it under the Public Domain dedication (i.e.
CC0).?? (I agree that MIT is weird here).
* Afterwards, I make a subset of my original data by removing any
roads I found elsewhere, e.g. in a proprietary source.
* And now you are saying that the new _subset_ of my original
public domain data is no longer public domain because I removed
values that exist??in a proprietary source?

Yes, it is a derivative work. (AFAIK)

___
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-de] Windy Map mißachtet OSM-Lizenz?

[Martin Koppenhoefer]

sent from a phone

> On 14. Nov 2019, at 21:23, Robert Grübler  wrote:
> 
> Hast Du sie mal kontaktiert?
> 
> Die OSMF? Nein - die jüngste Diskussion zwischen Nuno Caldeira und OSMF war 
> zu abschreckend.


Ich meinte ob Du Windy kontaktiert hast, vielleicht haben sie das mit der 
Lizenz ja nur übersehen o_O

nachdem wir der OpenStreetMap-Foundation beim Lizenzwechsel weitgehende Rechte 
eingeräumt haben, wäre es an ihnen, rechtlich vorzugehen. Da wir prinzipiell an 
der Nutzung unserer Daten (unter Beachtung der Lizenz) interessiert sind, wird 
man das vermutlich wie immer „soft“ angehen und höchstens nach vielen Monaten 
oder gar Jahren die Kanonen auspacken, wenn überhaupt. Bei Apple hatte man z.B. 
4 Jahre Geduld (aufgrund der Wichtigkeit wurde das zunächst direkt vom Board 
übernommen bevor es nach ein paar Monaten an die LWG zurückging), bei Microsoft 
hat man auch geduldet dass sie ein Jahr oder so ein abgeleitetes Werk (Blurring 
von Militärarealen auf Luftbildern in Deutschland anhand von 
OpenStreetMapgeometrien) ohne Attribution verbreitet haben.

Jedenfalls, die Kanonen der Kontentindustrie wären das hier: 
https://www.dmca.com/FAQ/What-is-a-DMCA-Takedown

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

Re: [Talk-africa] Fix road problems around Africa with MapRoulette: Angola, Egypt, Kenya, Rwanda, South Africa, Tunisia & Uganda

[Andrew Wiseman via Talk-africa]

Hi everyone,

I created a new one related to protected areas — such as national parks, 
protected forests, marine protected areas and so on. Take a look

• Fixing protected area tagging in Africa: 
https://maproulette.org/browse/challenges/10847

Thanks,

Andrew 

Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 


> On Oct 23, 2019, at 2:29 PM, Andrew Wiseman  wrote:
> 
> Hi all,
> 
> We recently refreshed the MapRoulette challenges with new data, and added a 
> few more countries around the continent. Here are new links to them. Let me 
> know if you have any questions! 
> 
> https://github.com/osmlab/appledata/wiki/MapRoulette-Challenges#africa
> 
> Thanks,
> 
> Andrew 
> 
> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com
> 
>> On Sep 6, 2019, at 4:45 PM, Andrew Wiseman  wrote:
>> 
>> Hello OSM Africa,
>> 
>> This is Andrew again with Apple’s Maps team. We recently used our Atlas data 
>> analysis tool (https://github.com/osmlab/atlas) to look at a few types of 
>> potential issues related to roads and routing, such as overly sharp road 
>> angles, roads that cross but don't connect, routing problems, turn 
>> restrictions, places where navigation is impossible due to missing 
>> connections or potentially incorrect one-way roads, and other similar issues.
>> 
>> I've posted the results of those checks on MapRoulette, a tool that lets you 
>> go through potential issues one by one and either correct them or indicate 
>> they are not a problem. I wanted to let you know they are available in case 
>> others wanted to try fixing some of them — I also plan to go through some of 
>> them myself.
>> 
>> In MapRoulette you can either pick a random task to fix or click on a 
>> specific one. If you want to do tasks around a certain location, such as 
>> somewhere you are familiar with, you can click on one from the map view, and 
>> then click Next task: Nearby when you finish it.
>> 
>> We ran the tool for a few countries recently: 
>> 
>> South Africa:
>> 
>> Crossing roads: https://maproulette.org/browse/challenges/8863
>> Routing problems: https://maproulette.org/browse/challenges/8855
>> Floating and disconnected roads: 
>> https://maproulette.org/browse/challenges/8852
>> Road connectivity check: https://maproulette.org/browse/challenges/8861
>> Invalid lanes: https://maproulette.org/browse/challenges/8860
>> Invalid turn restriction: https://maproulette.org/browse/challenges/8862
>> Malformed roundabouts: https://maproulette.org/browse/challenges/8859
>> Road links: https://maproulette.org/browse/challenges/8853
>> 
>> Uganda:
>> 
>> Crossing roads: https://maproulette.org/browse/challenges/8890
>> Routing problems: https://maproulette.org/browse/challenges/8892
>> Floating and disconnected roads: 
>> https://maproulette.org/browse/challenges/8894
>> Road connectivity check: https://maproulette.org/browse/challenges/8897
>> Invalid lanes: https://maproulette.org/browse/challenges/8896
>> Invalid turn restriction: https://maproulette.org/browse/challenges/8901
>> Malformed roundabouts: https://maproulette.org/browse/challenges/8899
>> 
>> Kenya:
>> 
>> Impossible routing: https://maproulette.org/browse/challenges/8734
>> Floating and disconnected roads: 
>> https://maproulette.org/browse/challenges/8735
>> Sharp road angles: https://maproulette.org/browse/challenges/8737
>> Crossing roads: https://maproulette.org/browse/challenges/8740
>> Connectivity check: https://maproulette.org/browse/challenges/8741
>> Invalid turn restrictions: https://maproulette.org/browse/challenges/8742
>> 
>> Rwanda:
>> 
>> Crossing roads: https://maproulette.org/browse/challenges/8850
>> Routing problems: https://maproulette.org/browse/challenges/8847
>> Floating and disconnected roads: 
>> https://maproulette.org/browse/challenges/8843
>> Road connectivity check: https://maproulette.org/browse/challenges/8848
>> Invalid turn restriction: https://maproulette.org/browse/challenges/8845
>> 
>> Egypt:
>> 
>> Impossible routing: https://maproulette.org/browse/challenges/8686
>> Sharp road angles: https://maproulette.org/browse/challenges/8688
>> Connectivity problems: https://maproulette.org/browse/challenges/8692
>> Malformed roundabouts: https://maproulette.org/browse/challenges/8690
>> Turn restriction problems: https://maproulette.org/browse/challenges/8693
>> Road links: https://maproulette.org/browse/challenges/8687
>> Crossing roads: https://maproulette.org/browse/challenges/8694
>> 
>> Angola:
>> 
>> Routing problems: https://maproulette.org/browse/challenges/8399
>> Floating and disconnected roads: 
>> https://maproulette.org/browse/challenges/8398
>> Road connectivity check: https://maproulette.org/browse/challenges/8402
>> Invalid turn restriction: https://maproulette.org/browse/challenges/8397
>> Malformed roundabouts: https://maproulette.org/browse/challenges/8401
>> 
>> Tunisia:
>> 
>> Impossible routing: 

Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?

[Mateusz Konieczny]

14 Nov 2019, 22:12 by yuriastrak...@gmail.com:

> Let me get this straight:
>
> * I create a dataset from public data sources, e.g. a list of roads, and 
> publish it under the Public Domain dedication (i.e. CC0).  (I agree that MIT 
> is weird here).
> * Afterwards, I make a subset of my original data by removing any roads I 
> found elsewhere, e.g. in a proprietary source.
> * And now you are saying that the new _subset_ of my original public domain 
> data is no longer public domain because I removed values that exist in a 
> proprietary source?
>
Yes, it is a derivative work. (AFAIK)___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] Windy Map mißachtet OSM-Lizenz?

[streckenkundler]

Guten Abend,

ja... Jeder dürfte seinen Honeypot in seiner Gegend haben... Ich erkenne in
meinem heimatlichen Spreewald genau, was OSM ist... Und ja, es ist OSM und
ja, es fehlt der Lizenzhinweis... Du kannst ja mal einen freudlichen Hinweis
senden, mit dem Verweis darauf, daß ein Hinweis entsprechend  
https://www.openstreetmap.org/copyright
   fehlt... und dann hier
berichten. Ich würde es als direkten Linkt auf der Karte erwarten und/oder
ergänzend wie es die OpenTopoMap macht:  https://opentopomap.org/about
  

Sven



--
Sent from: http://gis.19327.n8.nabble.com/Germany-f5281960.html

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

Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?

[Yuri Astrakhan]

Let me get this straight:

* I create a dataset from public data sources, e.g. a list of roads, and
publish it under the Public Domain dedication (i.e. CC0).  (I agree that
MIT is weird here).
* Afterwards, I make a subset of my original data by removing any roads I
found elsewhere, e.g. in a proprietary source.
* And now you are saying that the new _subset_ of my original public domain
data is no longer public domain because I removed values that exist in a
proprietary source?

I think this is taking it a bit too far, but IANAL... You are obviously
welcome to take it to court, but I think it will be a breach of trust if
OSMF would spend donated funds on fighting windmills. If anything, it will
stop any serious organization from ever touching anything related to OSM -
as they would never know what lawsuits might be brought up against them,
thus effectively killing OSM.

I feel there are some members of OSM community that ideologically opposed
to Facebook in general. I can understand that position, but I don't think
it should affect our judgement of the actual contribution, which only makes
our data better. The last thing we would want is for OSM to become a legal
minefield.

On Thu, Nov 14, 2019 at 3:47 PM Mateusz Konieczny 
wrote:

>
>
>
> 14 Nov 2019, 21:38 by r...@technomancy.org:
>
> Facebook provide download dumps of their machine detected roads on a
> country by country basis
>
> IANAL, but as far as i know you are
> 100% right.
>
> Also, is their road detection powered
> by already mapped OSM roads?
> In such case it would be ODBL even
> before substraction of what is in OSM.
> ___
> 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] Licence of Facebook's derived road datasets? ODbL?

[Christoph Hormann]

On Thursday 14 November 2019, Rory McCann wrote:
>
> That webpage says the data is MIT licenced (_data_ under MIT is odd,
> but whatever). The files are zipfiles with a licence file also saying
> MIT. The description is “Country exports contain only the AI
> predicted roads that are missing from OpenStreetMap”. That makes me
> think this data is a dervived database of OSM, and hence should be
> ODbL.

I think you are correct - and the OSMF seems to share this position - 
see the last example of "you DO need to share" on

https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Horizontal_Map_Layers_-_Guideline

and the last example on

https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Collective_Database_Guideline_Guideline

> A Facebook employee, long time OSMer, and fellow candidate for the
> OSMF board, answered the same way³.

While OSMF board candidates are of course in principle free to state 
their opinion on any forum of their choosing candidates should realize 
that doing so on a venue that requires community members to disclose 
personal data to a third party corporation to be able to participate or 
even to access the record of such communication is a very strong 
political statement.

Given that only one of this year's board candidates openly states to be 
working for facebook on their OSM user page - am i right to assume that 
the person you are talking about is Michal Migurski?

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

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

Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?

[Mateusz Konieczny]

14 Nov 2019, 21:38 by r...@technomancy.org:
> Facebook provide download dumps of their machine detected roads on a
> country by country basis
IANAL, but as far as i know you are
100% right.

Also, is their road detection powered
by already mapped OSM roads?
In such case it would be ODBL even
before substraction of what is in OSM.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Licence of Facebook's derived road datasets? ODbL?

[Rory McCann]

Hello all,

Facebook provide download dumps of their machine detected roads on a
country by country basis¹. It's great to see direct access to this data,
allowing us to look at that data without having to use a raw API. Well
done Facebook.

That webpage says the data is MIT licenced (_data_ under MIT is odd, but
whatever). The files are zipfiles with a licence file also saying MIT.
The description is “Country exports contain only the AI predicted roads
that are missing from OpenStreetMap”. That makes me think this data is a
dervived database of OSM, and hence should be ODbL.

If Facebook (or anyone) generate a road dataset, which we'll call D1,
from running their machine learning/neural network programme on aerial
imagery, and then removes roads from D1 which are in OSM, creating
dataset D2, then surely D2 is a “derived database” of OSM, and hence
ODbL requires D2 to also be ODbL, right? OSM data was used in the
creation of D2. To me D1 is “raw data derived from aerial imagery”, but
D2 is “raw data dervived from aerial imagery, plus OSM data”?

I asked if it should be ODbL, and Facebook reported that their legal
team believe MIT is correct².


We are extracting the data from Maxar satellite images (you can
learn about all the details from our publications) and our legal team
 believes this is the correct license. I am not planning to comment 
on the legal issues further; thank you for your curiosity.


A Facebook employee, long time OSMer, and fellow candidate for the OSMF
board, answered the same way³.

Good question Rory. That data is not derived from OSM. It’s just the 
raw road geometry inferences from aerial imagery.


The history of Facebook & OSM hasn't been 100% smooth sailing, and it
would be unfortunate if Facebook were to not obey the share-alike aspect
of our licence. I think we all agree that if FB released it under ODbL,
then everyone would be happy, and I urge them to do that.

Or am I missing something? Someone with more legal or licence knowledge
please correct me (or confirm I'm right)!

Rory


¹ 
https://github.com/facebookmicrosites/Open-Mapping-At-Facebook/wiki/Available-Countries

² https://github.com/facebookmicrosites/Open-Mapping-At-Facebook/issues/7
³ https://osmus.slack.com/archives/CK3BZ8FC0/p1573224740019300

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

Re: [Talk-de] Windy Map mißachtet OSM-Lizenz?

[Robert Grübler]

Am 14. November 2019 21:08 schrieb Martin Koppenhoefer 
[mailto:dieterdre...@gmail.com]
< M.E. ein Fall für die OpenStreetMap-Foundation, da kommerzieller Anbieter. 
Hast Du sie mal kontaktiert?

Die OSMF? Nein - die jüngste Diskussion zwischen Nuno Caldeira und OSMF war zu 
abschreckend.

LG Robert (robhubi)



-Ursprüngliche Nachricht-
Von: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] 
Gesendet: Donnerstag, 14. November 2019 21:08
An: Openstreetmap allgemeines in Deutsch 
Betreff: Re: [Talk-de] Windy Map mißachtet OSM-Lizenz?

auf dem Telefon ist m.E. nichtmal die winzige Attribution, gar nicht.

M.E. ein Fall für die OpenStreetMap-Foundation, da kommerzieller Anbieter. Hast 
Du sie mal kontaktiert? 

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] Windy Map mißachtet OSM-Lizenz?

[Martin Koppenhoefer]

auf dem Telefon ist m.E. nichtmal die winzige Attribution, gar nicht.

M.E. ein Fall für die OpenStreetMap-Foundation, da kommerzieller Anbieter. Hast 
Du sie mal kontaktiert? 

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

Re: [Talk-de] Windy Map mißachtet OSM-Lizenz?

[Martin Koppenhoefer]

sent from a phone

> On 14. Nov 2019, at 18:50, Robert Grübler  wrote:
> 
> Basiert die Karte in eurer Gegend auch auf OSM?


ja, in Rom ist es auch definitiv OpenStreetMap, wie Du schon schreibst, sie 
„attributieren“ es ja auch, wenn auch nicht wahrnehmbar, und osm antatt 
OpenStreetMap ist auch nicht zulässig.


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

[Talk-ee] SoTM Baltics 2020

[Rihards]

Hi, dear Estonian OSM community.

On 2020-03-06 there will be a Baltcic GIT/GIS conference in Riga with a
dedicated OSM track.
We're using the opportunity and turning it into
*drumroll*
SoTM Baltics :)

You are very welcome to attend, and we are also looking for:

* Speakers
That is You. Got anything you are doing with OSM? Please consider
submitting a talk proposal for the OSM track.
Please feel free to email me if you have a proposal or for any questions.

* Partners
If there are any companies in OSM space that would like to advertise at
the event - become sponsors/supporters - please let me know.
The available options can be found at
https://www.balticgitconf.eu/images/conference_2020/partnership_proposal.pdf
.

More info on the conference at https://www.balticgitconf.eu/ .

See you in March.
-- 
 Rihards

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

Re: [OSM-talk-fr] [OverpassTurbo] Manquent terminus dans ligne de métro

[marc marc]

Le 14.11.19 à 14:41, Shohreh a écrit :
> marc marc wrote
>> il y a quoi dans searchArea ? vu que tu sélectionnes les rails de la
>> relation, c'est peu probablement que tu doives à nouveau vérifier leur
>> étendue géographique
> 
> Par exemple, pour le RER A:
> 
> (relation["network"="RER"]["ref"="A"];) -> .searchArea;

ha... cela fonctionne. mais c'est assez embrouillant de sauver
une relation dans une variable habituellement utilisé pour sauver
une zone géographique.

du coup si tu n'as pas filtré sur une zone géographique,
tu vas avoir des résultats surprenant le jour un autre pays/région
a un RER A :)

en passant vire donc la () qui ne sert a rien ((la parenthèse
groupe plusieurs choses, hors ici tu en a qu'une)
relation["network"="RER"]["ref"="A"] -> .searchArea;
(tu ne spéficies pas que tu veux des routes, le jour oü qlq chose 
d'autre existe en network=RER + ref=A, tu vas l'avoir aussi
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-de] Windy Map mißachtet OSM-Lizenz?

[Robert Grübler]

Liebe Mapperinnen und Mapper im Nachbarland,
verzeiht den crosspost von talk-at, aber das Thema braucht breitere
Unterstützung.


Der letzte Wochennotiz hat mich auf die Windy Map aufmerksam gemacht. Schöne
Karte, zweifellos. 
Zumindest in meiner Gegend basiert sie mit Sicherheit auf OSM-Daten. 
Vergleicht selbst:
https://abload.de/img/omm_windy_sparkek47.jpg 
Der Sparmarkt ist neu, den gibt es so auf keinen Luftbild zu sehen. Das weiß
ich, weil ich es gemappt habe.

Hier die ganze Karte:
https://www.windy.com/de/-Wanderkarte-map?map,47.051,15.470,18

Seht ihr die Attributierung? Nein? Hier ist sie:
https://abload.de/img/omm_windy_cpr3fkp3.jpg
Ganz rechts unten. In winziger, weißer Schrift mit 70% Transparenz!

Basiert die Karte in eurer Gegend auch auf OSM?
Jedenfalls, die Urheberrechte so verschwindend zu würdigen, empfinde ich als
respektlos. 

Ich meine, wir sollten das nicht so einfach hinnehmen.
Ob die OSMF was tut weiß ich nicht, aber wir können und sollten etwas tun:

*** Deponiert eure Meinung im Windy Forum!
*** https://community.windy.com/topic/3353/map-correction/11 

Sprache egal. Höflich aber bestimmt.

Liebe Grüße
Robert (robhubi)



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

[talk-latam] Transmisión en línea de la conferencia SOTMLatam 2019

[Marco Antonio]

Hola,

Hay transmisión en línea de la conferencia SOTMLatam 2019 en Paraguay ↓

https://www.youtube.com/watch?v=L03-XwO4CT0

Desconozco si es un enlace para toda la conferencia, pero si cambia
mañana la anuncio..

Abrazos,

Marco Antonio

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

[Talk-bo] Transmisión en línea de la conferencia SOTMLatam 2019

[Marco Antonio]

Hola,

Hay transmisión en línea de la conferencia SOTMLatam 2019 en Paraguay ↓

https://www.youtube.com/watch?v=L03-XwO4CT0

Desconozco si es un enlace para toda la conferencia, pero si cambia
mañana la anuncio..

Abrazos,

Marco Antonio

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

Re: [OSM-talk-fr] prev.openstreetmap.fr

[marc marc]

Le 14.11.19 à 17:13, Vincent Bergeot a écrit :
> disons que la première étape est sans doute de référencer ce qui doit 
> être migrer de prev. à l'actuel :)
> 

2 pistes :

- utiliser un moteur de recherche pour voir ce qui est référencé
sur prev.*, vérifier que ce contenu est bien présent sur www.*
puis mettre une redirection de prev vers www.*

- analyser les logs web de prev.* pour commencer par ceux consultés.
Cette piste nécessitant quelqu'un qui veux remettre les stats en route
puisque le tentative précédente n'a pas abouti
ticket en question https://github.com/osm-fr/infrastructure/issues/17
a voir avec Maël s'il a rencontré un soucis ou manque de temps
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Le filtre anti spam du wiki râle

[Yves P.]

> pour ma part je ne vois pas l'intérêt de mettre un lien redirecteur
> le wiki permet de raccourcir l'url si on veux l'affichage ne soie pas 
> trop long
En soit, je peux m’en passer.

Le truc c’est que je veux documenter ce que les contributeurs mettent dans la 
base OSM.
C’est mieux si ces liens fonctionnent 

Comme il y en a pour bit.ly  et youtu.be , 
tant qu’à faire on peut en mettre pour flic.kr  

Actuellement, il est impossible de mettre de lien flic.kr. Ça fonctionne en 
prévisualisation, mais pas à l’enregistrement :

Errors:
The text you wanted to save was blocked by the spam filter.
This is probably caused by a link to a blacklisted external site.
The following text is what triggered our spam filter: flic.kr


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

Re: [OSM-talk-fr] Le filtre anti spam du wiki râle

[marc marc]

Le 14.11.19 à 17:31, Yves P. a écrit :

> j’ai du bricoler pour mettre un lien vers https://flic.kr 
> 

pour ma part je ne vois pas l'intérêt de mettre un lien redirecteur
le wiki permet de raccourcir l'url si on veux l'affichage ne soie pas 
trop long
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Le filtre anti spam du wiki râle

[Yves P.]

@Vincent

> Oui pour documenter « facilement » la clé flickr. 
…sur le wiki :
https://wiki.openstreetmap.org/wiki/Key:flickr
https://wiki.openstreetmap.org/wiki/Talk:Key:flickr (ici où j’ai du bricoler 
pour mettre un lien vers https://flic.kr/p/2h8YVBv)

> Regarde le contenu du fichier de configuration 
https://wiki.openstreetmap.org/wiki/MediaWiki:Spam-whitelist

Je faisais écho à ta question :
> est-ce vraiment utile d'ajouter un nom de domaine qui est dédié à des 
> redirections sur une autre url 

J’espère avoir été plus clair 

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

Re: [Talk-it] Tagging scheme alimentare

[Martin Koppenhoefer]

sent from a phone

> On 14. Nov 2019, at 11:01, Cascafico Giovanni  wrote:
> 
> Si tratta di assegnare delle chiavi e valori ad
> attività come prosciuttifici, norcini, catering e gastronomie ecc.
> Molti elementi del dataset non hanno la rivendita, per cui escludo la
> chiave shop. Per il resto...
> 
> - man_made si riferisce alla struttura fisica e non all'attività
> - industrial si riferisce all'uso del suolo (slaughterhouse è
> wikizzato solo su industrial)


direi che industrial non è adatto in nessun caso per descrivere una entità, se 
presumiamo che si riferisca al uso del suolo. Anche per slaughterhouse come 1 
mattatoio si vorrebbe un’altro tag che landuse e industrial (probabilmente un 
tag man_made).



> 
> Deduco quindi che resti man_made=works [1] e craft [2] .


+1


> ..La wiki poi
> apre un dubbio sui volumi di lavorazione/produzione che dovrebberio
> discriminare tra
> 
> craft=meat|beer|dairy| ecc...


no, craft descrive una professione, non un prodotto 

sarebbe craft=cheesemaker/brewer/butcher/...


> 
> oppure la coppia
> man_made=works
> product=meat|beer|dairy| ecc...


si, se la scala è industriale 


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

Re: [OSM-talk-fr] Le filtre anti spam du wiki râle

[Vincent Bergeot]

Le 13/11/2019 à 07:36, Yves P. a écrit :


est-ce vraiment utile d'ajouter un nom de domaine qui est dédié à des 
redirections sur une autre url : si je comprends bien le cas que tu 
présentes.



Oui pour documenter « facilement » la clé flickr.
Regarde le contenu du fichier de configuration 


je ne sais pas à quoi tu fais référence :(

à plus

--
Vincent Bergeot


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

Re: [OSM-talk-fr] prev.openstreetmap.fr

[Vincent Bergeot]

Le 13/11/2019 à 20:36, Cédric Frayssinet a écrit :

Tout l'intérêt d'avoir encore l'ancien site sous la main c'est d'y
trouver des ressources qu'on ne trouve pas ailleurs. Donc ne plus
l'indexer n'est pas la solution. Migrer d'abord, éteindre ensuite, ça
oui. Mais c'est fastidieux, et sur ce sujet comme sur d'autres les
bonnes volontés sont les bienvenues.


Si vous me dites ce qu'il faut migrer, je peux m'y coller à temps perdu.
Je connais bien WP, pas du tout Drupal mais ce n'est pas très grave pour
ce boulot ingrat:).


disons que la première étape est sans doute de référencer ce qui doit 
être migrer de prev. à l'actuel :)


pas de souci pour t'ouvrir les droits ensuite sur WP, il suffit de se 
connecter avec son compte osm, on attribue ensuite les droits 
correspondants.


Merci :)

--
Vincent Bergeot

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

[Talk-it] Special Issue "OpenStreetMap as A Multi-Disciplinary Nexus: Perspectives, Practices and Procedures"

[Marco Minghini]

Ciao,
scusandomi per il cross-posting, di seguito l'invito alla Special Issue su
OpenStreetMap che ho organizzato insieme ai colleghi dell'Academic Track di
State of the Map 2019.
Un saluto a tutti,
Marco




Dear Colleagues,

We are excited to invite you to submit a research paper to “OpenStreetMap
as a multi-disciplinary nexus: Perspectives, Practices and Procedures
”, a
Special Issue of the *ISPRS International Journal of Geo-Information*. The
aim of this Special Issue is to showcase both the ongoing innovation and
the maturity of scientific investigations and research into OpenStreetMap,
demonstrating how, as a research object, it converges multiple research
areas together. Collecting contributions from multiple disciplines and
domains, the Special Issue will show how the sum total of investigations of
issues like VGI, geo-information, and geo-digital processes and
representations can shed light on the relations between crowds, real-world
applications, technological developments, and scientific research.

This Special Issue is primarily aimed at collecting papers that extend the
research works presented in the Academic Track
 of State of the Map
2019 , held in Heidelberg (Germany) on
September 21–23, 2019. However, other original submissions aligned with the
area of research are also highly welcome.

We expect empirical, methodological, or conceptual contributions addressing
any scientific aspect related to OpenStreetMap, in particular, but not
limited, to the following:

   - Extrinsic and intrinsic quality assessment of OpenStreetMap data
   - Analysis of contribution patterns in OpenStreetMap
   - Interactions between OpenStreetMap and other data sources
   - Analysis/comparison of available software for scientific purposes
   related to OpenStreetMap
   - New approaches to facilitate or improve data collection in
   OpenStreetMap (e.g., through gamification or citizen science approaches)
   - Bridging the communities: Creating better connections and
   collaborations between the scientific community and the OpenStreetMap
   community
   - Open research problems in OpenStreetMap and challenges for the
   scientific community
   - Cultural, political, and organizational aspects of data production and
   usage practices in OpenStreetMap
   - Literature reviews and theoretical papers on any of the listed topics
   or topics related to the scope of the Special Issue

Dr. A. Yair Grinberger
Dr. Marco Minghini
Dr. Peter Mooney
Dr. Levente Juhász
Dr. Godwin Yeboah
*Guest Editors*
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-se] Märklig kustlinje

[Peter Svensson]

Uppdateringen av kustlinjen släpar efter. Jag tror det kommer lösa sig
själv.

Det verkar inte finnas någon way där kustlinjen nu syns.

Mvh

Den tors 14 nov. 2019 14:39Björn Stenberg  skrev:

> Hej,
>
> Är det någon som kan lista ut vad det är som ger Siarö en vit
> bakgrund/kustlinje som inte syns i någon editor?
>
> Titta på Skutviken här
> https://www.openstreetmap.org/#map=17/59.56153/18.67075
>
> Den är rendrerad på en vit yta som inte finns i datat. I såväl JOSM som iD
> är Skutviken en vanlig havsvik som borde rendreras blå som resten av havet.
> Det är likadant runt hela ön.
>
> --
> Björn (Zagor)
>
> ___
> 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: [OSM-talk] bridging chatrooms

[Martin Koppenhoefer]

enabling IRC to telegram posts would likely also attract spammers, we have
had some few spam incidents on OSM Telegram groups, but with an IRC bridge
it may increase a lot...

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

Re: [OSM-talk-fr] [OverpassTurbo] Manquent terminus dans ligne de métro

[Shohreh]

marc marc wrote
> il y a quoi dans searchArea ? vu que tu sélectionnes les rails de la
> relation, c'est peu probablement que tu doives à nouveau vérifier leur
> étendue géographique

Par exemple, pour le RER A:

(relation["network"="RER"]["ref"="A"];) -> .searchArea;

Si un site quelque part propose les GPX des lignes RER/Transilien avec les
stations en nodes comme je cherche, ça m'éviterait de refaire (même si ça
permet d'apprendre des choses utiles pour plus tard), mais j'ai pas trouvé.



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

[Talk-se] Märklig kustlinje

[Björn Stenberg]

Hej,

Är det någon som kan lista ut vad det är som ger Siarö en vit
bakgrund/kustlinje som inte syns i någon editor?

Titta på Skutviken här
https://www.openstreetmap.org/#map=17/59.56153/18.67075

Den är rendrerad på en vit yta som inte finns i datat. I såväl JOSM som iD
är Skutviken en vanlig havsvik som borde rendreras blå som resten av havet.
Det är likadant runt hela ön.

--
Björn (Zagor)
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

[OSM-ja] 12/14 京都！街歩き！マッピングパーティ：第15回 南禅寺

[yasunari yamashita]

京都！街歩き！マッピングパーティ世話役の山下です。
皆さんこんにちわ。

京都を街歩きして、楽しみながら 自由な地図である OpenStreetMap を創り上げていくマッピングパーティ！

12 月の京都！街歩き！マッピングパーティは、
絶景かな！で有名な三門のある京都五山 別格 南禅寺

イベントの詳細と参加申し込みは connpass にて
https://openstreetmap-kyoto.connpass.com/event/11/

皆様の参加をお待ちしています！
--
山下康成＠京都府向日市
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] [OverpassTurbo] Manquent terminus dans ligne de métro

[marc marc]

Le 14.11.19 à 14:00, Shohreh a écrit :
> Nicolas Bétheuil-2 wrote
> Comme la question des "bouts de ways qui dépassent des terminus" se pose
> souvent, y a-t-il une syntaxe plus smart que les matryoshkas pour les
> supprimer toutes d'un  coup ?

pour les chemins de fer, il y un tag pour dire si c'est service voyageur 
ou si c'est infra de service.
je te conseille de lire la page wiki chemin de fer pour voir si tu 
pourrais t'en inspirer pour marquer les rails après le dernier arrêt

>way(r.searchArea:"") ;

il y a quoi dans searchArea ?
vu que tu sélectionnes les rails de la relation,
c'est peu probablement que tu dooives à nouveau
vérifier leur étendue géographique
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OverpassTurbo] Manquent terminus dans ligne de métro

[Shohreh]

Nicolas Bétheuil-2 wrote
> En gros pour faire vite, il y a une nomenclature hiérarchisé :
>  - les routes master représente la ligne
>  - Qui ont des relations vers les routes, chaque sens
>  - qui contient des points, le dessin de la ligne, les stations etc ...
> 
> La route master n’a pas de définition géographique, aucun point mais les
> route oui.

Merci.

Comme la question des "bouts de ways qui dépassent des terminus" se pose
souvent, y a-t-il une syntaxe plus smart que les matryoshkas pour les
supprimer toutes d'un  coup ?


(
(
  way(r.searchArea:"") ;
  node(r.searchArea) ;
); - way(20948844);
); - way(356574270);
);







--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [Talk-GB] Tagging Mill Races / Leats / Lades

[Martin Wynne]

On 14/11/2019 12:31, Ken Kilfedder wrote:

Per the wiki "Use waterway=canal for man-made open flow (free flow vs pipe flow) 
waterways used to carry useful water for transportation, hydro-power generation OR 
irrigation purposes."   E.g. there are a range of purposes for which waterway=canal 
is used.


But see: https://en.wikipedia.org/wiki/Aqueduct_(water_supply)

"An aqueduct is a watercourse constructed to carry water
...in modern engineering, the term aqueduct is used for any system of 
pipes, ditches, canals, tunnels, and other structures used for this purpose.

...The simplest aqueducts are small ditches cut into the earth"

Martin.

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

[OSM-talk] bridging chatrooms

[joost schouppe]

Hi,

In the run-up to SotM there were some (justified) complaints that the
chatroom for the event was only available using Telegram. I'm not
interested in a discussion about whether this is no issue at all or rather
a Big Issue. I'd rather just fix the issue, without forcing anyone to
change. It should be relatively easy to bridge Telegram to IRC. But it
seems to require a tool installed on a server. Is there anyone who has
experience with this? And especially: is willing to host it somewhere?

I have a similar issue with a room I've set up in Matrix. It bridges
perfectly to IRC, but the bridge to Telegram hosted by tchncs.de keeps
failing. Does anyone here know how to fix such issues?
I think it might be an interesting solution to have an OSMF hosted Matrix
server and use that as a central hub to bridge several chat systems to each
other.

It is also annoying that discussion on some platforms can only be accessed
if you have an account for that platform. On some platforms, the person who
started the channel, can just delete all messages. And of course there's
also the risk that the platform operator disappears or starts charging for
access to history. So a next step would be to start archiving conversations
in a searchable way. Maybe something like CSV, maybe just using (for
example) an OSMF hosted Matrix server. This could then maybe be linked to
OSM accounts. Semi-public archiving would need to be opt-in, since people
often consider chat a fleeting medium which they would prefer not to be
quoted on.

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

Re: [Talk-GB] Tagging Mill Races / Leats / Lades

[Colin Smale]

On 2019-11-14 13:22, Martin Wynne wrote:

> "Canal" should surely be restricted to transport functions? Boating apps 
> presumably treat "canal" as a route unless navigation restrictions are added.

Canal indicates a form of construction - man-made. Unlike natural
watercourses they were constructed because someone had a purpose in
mind, which might have been anything... Transport (using boats/barges),
moving water about, decoration, powering watermills, providing a relief
route to a river, improving the navigability of a river...___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Tagging Mill Races / Leats / Lades

[Ken Kilfedder]

Per the wiki "Use waterway=canal for man-made open flow (free flow vs pipe 
flow) waterways used to carry useful water for transportation, hydro-power 
generation OR irrigation purposes."   E.g. there are a range of purposes for 
which waterway=canal is used.

The access tags could be used to make it clear - access=no and/or boat=no.

---
https://hdyc.neis-one.org/?spiregrain
spiregrain_...@ksglp.org.uk

On Thu, 14 Nov 2019, at 12:22 PM, Martin Wynne wrote:
> "Canal" should surely be restricted to transport functions? Boating apps 
> presumably treat "canal" as a route unless navigation restrictions are 
> added.
> 
> If the stuff that is moving is the water rather than the boats, 
> "aqueduct" would be the correct term.
> 
> cheers,
> 
> Martin.
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>

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

Re: [Talk-GB] Tagging Mill Races / Leats / Lades

[Paul Berry]

I pieced it together as best I could and came up with that, which reminds
me that we need much better (UK-specific) tagging information on the Wiki.

Nothing stopping anyone rolling their own tags though. I'd have gone for
man_made=leat which has some small precedent.

Regards,
*Paul*

On Thu, 14 Nov 2019 at 12:25, Dan S  wrote:

> I think instead of canal=headrace you meant to write usage=headrace?
> That's what's in the wiki, and also 1000+ entries seen in taginfo.
>
> I've chatted many times to people about millraces, but the term
> "headrace" (and "tailrace") is new to me. I'll add keywords to the
> wiki to make searching easier.
>
> Best
> Dan
>
> Op do 14 nov. 2019 om 11:53 schreef Paul Berry :
> >
> > Looking at the existing guidelines it would be waterway=canal and
> canal=headrace (canal here used in the power rather than transport context)
> >
> > If this is indeed correct then it's not very obvious but it is detailed
> here:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Hydropower_water_supplies#Headraces
> >
> > Regards,
> > Paul
> >
> > On Thu, 14 Nov 2019 at 11:16, Charlie Reid  wrote:
> >>
> >> Hi
> >>
> >>
> >>
> >> Can find no guidance on the Wiki about tagging mill races. I come
> across these continually while surveying.
> >>
> >>
> >>
> >> They are a totally distinctive water feature which don’t bear much
> relation to listed waterway types. Drain seems to be the closes value – but
> this really misrepresents  their appearance, purpose and behaviour.
> >>
> >>
> >>
> >> Any thoughts
> >>
> >>
> >>
> >> Charlie Reid
> >>
> >>
> >>
> >>
> >>
> >> ___
> >> Talk-GB mailing list
> >> Talk-GB@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-gb
> >
> > ___
> > Talk-GB mailing list
> > Talk-GB@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Tagging Mill Races / Leats / Lades

[Dan S]

I think instead of canal=headrace you meant to write usage=headrace?
That's what's in the wiki, and also 1000+ entries seen in taginfo.

I've chatted many times to people about millraces, but the term
"headrace" (and "tailrace") is new to me. I'll add keywords to the
wiki to make searching easier.

Best
Dan

Op do 14 nov. 2019 om 11:53 schreef Paul Berry :
>
> Looking at the existing guidelines it would be waterway=canal and 
> canal=headrace (canal here used in the power rather than transport context)
>
> If this is indeed correct then it's not very obvious but it is detailed here: 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Hydropower_water_supplies#Headraces
>
> Regards,
> Paul
>
> On Thu, 14 Nov 2019 at 11:16, Charlie Reid  wrote:
>>
>> Hi
>>
>>
>>
>> Can find no guidance on the Wiki about tagging mill races. I come across 
>> these continually while surveying.
>>
>>
>>
>> They are a totally distinctive water feature which don’t bear much relation 
>> to listed waterway types. Drain seems to be the closes value – but this 
>> really misrepresents  their appearance, purpose and behaviour.
>>
>>
>>
>> Any thoughts
>>
>>
>>
>> Charlie Reid
>>
>>
>>
>>
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [Talk-GB] Tagging Mill Races / Leats / Lades

[Martin Wynne]

"Canal" should surely be restricted to transport functions? Boating apps 
presumably treat "canal" as a route unless navigation restrictions are 
added.


If the stuff that is moving is the water rather than the boats, 
"aqueduct" would be the correct term.


cheers,

Martin.

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

Re: [Talk-es] Mapeo de espacios protegidos

[Agustin Diez-Castillo]

Olivier,
Está también la lista de patrimonio mundial de la UNESCO [1] que supongo que en 
su mayor parte estarán subidos, pero hay elementos que son multilocales, 
algunas con hasta 758 sitios [2], que no es por criticar a la UNESCO pero 
algunos tienen las coordenadas mal, difícil tarea. Además la UNESCO solo da un 
punto para cada lugar, pero obviamente todos esos lugares son, por ley, Bienes 
de Interés Cultural (BIC) y estos están definidos por polígonos.
Como supones, hay más espacios protegidos de los que mencionas, como “jardines 
históricos”, Bienes de Interés Cultura (BIC), Bienes de Relevancion Local (BRL) 
en la comunidad valenciana, además de zonas arqueológicas, por mencionarte unos 
cuantos y las combinaciones entre todas esas categorías y las que tu mencionas 
se pueden dar.
El miteco tiene una capa shape con todos los LIC [3] y otra con las ZEPA [4] 
que puede ser un buen sitio para empezar, no tengo idea de su licencia aunque 
en la página de metadatos de la Red Natura 2000 [5] dice que la licencia es 
http://creativecommons.org/licenses/by-sa/3.0/es/. Creo que en realidad los 
datos son de la UE [6] y quiero imaginar que su licencia permite usarlos en OSM.
[1] http://whc.unesco.org/en/list/
[2] http://whc.unesco.org/en/list/874/multiple=1_number=1026
[3] 
https://www.miteco.gob.es/es/biodiversidad/servicios/banco-datos-naturaleza/informacion-disponible/rednatura_2000_lic_descargas.aspx
[4] 
https://www.miteco.gob.es/en/biodiversidad/servicios/banco-datos-naturaleza/informacion-disponible/rednatura_2000_zepa_descargas.aspx
[5] 
https://www.mapama.gob.es/ide/metadatos/srv/spa/metadata.show?uuid=0d427e21-be52-4723-b78e-8b00a43319cb
[6] 
https://www.eea.europa.eu/data-and-maps/data/natura-10/natura-2000-spatial-data

> On 14 Nov 2019, at 12:21, bobeeeze  wrote:
> 
> Buenos días,
> Estoy un poco pesimista respecto a la prosperidad de este tema.
> Efectivamente es lo que siento después de ver la complejidad de la realidad,
> la complejidad de la transcripción al mapa y lo poco de respuesta que ha
> recibido mi mensaje que supongo traducirá el poco de entusiasmo que levanta
> este tema.
> La complejidad de la realidad, me he topado con ella buscando información
> sobre los espacios protegidos. Y eso que he buscado solo en la comunidad
> valenciana. Supongo que eso habrá que multiplicarlo por la cantidad de
> comunidades autónomas que cuenta España, o casi. He podido ver por ejemplo
> en el visor del "institut Cartogràfic Valencià" que existen:
> - monumentos naturales
> - parques naturales
> - reservas naturales
> - zonas húmedas
> - parajes naturales municipales
> - paisajes protegidos
> - red Natura2000 (con los LIC, ZEC y ZEPA)
> - reservas de fauna
> Además, muchas zonas protegidas pertenecen a varias de esas categorías de
> espacios protegidos y para colmo tienen limites diferentes en cada
> categoría.
> Os dejo un enlace al visor del ICV [1] para que veáis mejor. He activado las
> capas que representan las categorías que nombro arriba.
> Evidentemente, esa información no puede ser utilizada por problema de
> licencia dado que el ICV todavía no ha dado su permiso explicito. Supongo
> que al nivel nacional podríamos ver si la información compartida y
> autorizada del IGN contiene esos datos. También me he dado cuenta que hay
> varias fuentes posibles en varios ministerios (MITECO: Ministerio para la
> Transición Ecológica, MAPAMA: Ministerio de Agricultura y Pesca,
> Alimentación y Medio Ambiente). No sé si es lo mismo pero duplicado o es
> diferente y cada uno tiene un tipo de información. En fin, que no nos
> facilita el trabajo.
> 
> Una vez toda esa información digerida, ahora vendría el momento de la
> transcripción al mapa de todo eso. Y ahí tengo varias preguntas.
> 
> Para empezar ¿Como se realizaría? Importación o manualmente? Importación no
> tengo idea de como funciona, solo he visto un poco el proceso de importación
> del catastro y la única parte donde podría participar es la fase final de
> comprobación y subida de datos. Me gusta esta solución pero primero hay que
> encontrar personas dispuesta a hacer toda la parte preparativa de
> tratamiento de los datos (en caso de conseguirlos). 
> Manualmente, se necesita más tiempo pero bueno poco a poco, todo se
> consigue. Y mejor así que no hacer nada. Cada uno hace los de su zona. El
> inconveniente es que suelen abarcar zonas grandes o muy grandes,lo que
> significa que es complicado y costoso mapearlo. También sería complicado
> saber en que estado (progreso) se encuentra la introducción de toda esa
> información en OSM 
> 
> ¿Que información tratamos? Parques? Monumentos? LIC? ZEPA? todo a la vez?
> Supongo que sería más fácil ir categoría por categoría. También habría que
> ver que etiquetas se pone para cada categoría (quizás hacer un preset como
> el de los BIC)
> 
> ¿Como se han mapeado los parques y espacios protegidos en España ya
> existentes en OSM? Alguien que lea eso y haya participado en la creación de
> uno nos 

Re: [Talk-GB] Tagging Mill Races / Leats / Lades

[Paul Berry]

Looking at the existing guidelines it would be waterway=canal and
canal=headrace (canal here used in the power rather than transport context)

If this is indeed correct then it's not very obvious but it is detailed
here:
https://wiki.openstreetmap.org/wiki/Proposed_features/Hydropower_water_supplies#Headraces

Regards,
*Paul*

On Thu, 14 Nov 2019 at 11:16, Charlie Reid  wrote:

> Hi
>
>
>
> Can find no guidance on the Wiki about tagging mill races. I come across
> these continually while surveying.
>
>
>
> They are a totally distinctive water feature which don’t bear much
> relation to listed waterway types. Drain seems to be the closes value – but
> this really misrepresents  their appearance, purpose and behaviour.
>
>
>
> Any thoughts
>
>
>
> Charlie Reid
>
>
>
>
> ___
> 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-es] Mapeo de espacios protegidos

[bobeeeze]

Buenos días,
Estoy un poco pesimista respecto a la prosperidad de este tema.
Efectivamente es lo que siento después de ver la complejidad de la realidad,
la complejidad de la transcripción al mapa y lo poco de respuesta que ha
recibido mi mensaje que supongo traducirá el poco de entusiasmo que levanta
este tema.
La complejidad de la realidad, me he topado con ella buscando información
sobre los espacios protegidos. Y eso que he buscado solo en la comunidad
valenciana. Supongo que eso habrá que multiplicarlo por la cantidad de
comunidades autónomas que cuenta España, o casi. He podido ver por ejemplo
en el visor del "institut Cartogràfic Valencià" que existen:
- monumentos naturales
- parques naturales
- reservas naturales
- zonas húmedas
- parajes naturales municipales
- paisajes protegidos
- red Natura2000 (con los LIC, ZEC y ZEPA)
- reservas de fauna
Además, muchas zonas protegidas pertenecen a varias de esas categorías de
espacios protegidos y para colmo tienen limites diferentes en cada
categoría.
Os dejo un enlace al visor del ICV [1] para que veáis mejor. He activado las
capas que representan las categorías que nombro arriba.
Evidentemente, esa información no puede ser utilizada por problema de
licencia dado que el ICV todavía no ha dado su permiso explicito. Supongo
que al nivel nacional podríamos ver si la información compartida y
autorizada del IGN contiene esos datos. También me he dado cuenta que hay
varias fuentes posibles en varios ministerios (MITECO: Ministerio para la
Transición Ecológica, MAPAMA: Ministerio de Agricultura y Pesca,
Alimentación y Medio Ambiente). No sé si es lo mismo pero duplicado o es
diferente y cada uno tiene un tipo de información. En fin, que no nos
facilita el trabajo.
 
Una vez toda esa información digerida, ahora vendría el momento de la
transcripción al mapa de todo eso. Y ahí tengo varias preguntas.

Para empezar ¿Como se realizaría? Importación o manualmente? Importación no
tengo idea de como funciona, solo he visto un poco el proceso de importación
del catastro y la única parte donde podría participar es la fase final de
comprobación y subida de datos. Me gusta esta solución pero primero hay que
encontrar personas dispuesta a hacer toda la parte preparativa de
tratamiento de los datos (en caso de conseguirlos). 
Manualmente, se necesita más tiempo pero bueno poco a poco, todo se
consigue. Y mejor así que no hacer nada. Cada uno hace los de su zona. El
inconveniente es que suelen abarcar zonas grandes o muy grandes,lo que
significa que es complicado y costoso mapearlo. También sería complicado
saber en que estado (progreso) se encuentra la introducción de toda esa
información en OSM 

¿Que información tratamos? Parques? Monumentos? LIC? ZEPA? todo a la vez?
Supongo que sería más fácil ir categoría por categoría. También habría que
ver que etiquetas se pone para cada categoría (quizás hacer un preset como
el de los BIC)

¿Como se han mapeado los parques y espacios protegidos en España ya
existentes en OSM? Alguien que lea eso y haya participado en la creación de
uno nos podría comentar como se hizo y las fuentes utilizadas por ejemplo.

Bueno y ahora la gran pregunta: ¿¿Quién se anima??

Un saludo

Olivier

[1]
https://visor.gva.es/visor/?extension=474050,4237918,923348,4467314=9=Basica_5000;,Espacios_Protegidos;10,Espacios_Protegidos;3,Espacios_Protegidos;11,Espacios_Protegidos;13,Espacios_Protegidos;18,Espacios_Protegidos;19,Espacios_Protegidos;22,Espacios_Protegidos;23,Espacios_Protegidos;24=1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0=es



--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html

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

[Talk-GB] Tagging Mill Races / Leats / Lades

[Charlie Reid]

Hi

Can find no guidance on the Wiki about tagging mill races. I come across these 
continually while surveying.

They are a totally distinctive water feature which don't bear much relation to 
listed waterway types. Drain seems to be the closes value - but this really 
misrepresents  their appearance, purpose and behaviour.

Any thoughts

Charlie Reid


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

Re: [Talk-it] OSMit 2020

[canfe]

Ascolterei con interesse il tuo intervento!



--
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-se] Många nya öppna data från naturvårdsverket

[pangoSE]

Hej Henrik


On 2019-11-11 09:09, Henrik Larsson wrote:
Alla data är inte CC0 men kartdata verkar vara det. 


Se 
http://www.naturvardsverket.se/upload/miljoarbete-i-samhallet/uppdelat-efter-omrade/oppna-data/policy-naturvardsverkets-datainformation-2017-06-08.pdf 
för detaljer. Alla geodata och attributter är CC0 :D



Skulle vara intressant om vi kunde göra något med marktäckesdatan: 
https://www.naturvardsverket.se/Sa-mar-miljon/Kartor/Nationella-Marktackedata-NMD/
 Den ger oss nationell täckning på markanvändningen ner på 10-metersnivå 
uppdelat på 24 naturtyper.


Tyvärr har detta redan försökts. Se tidigare epost till listan. Jag har 
för nån vecka sedan föreslagit att vi stoppar importen tills vidare i 
väntan på bättre data/nån som är villig att städa upp och höja 
kvaliteten på det från NMD som redan importerats.


Mvh
pangoSE


-Ursprungligt meddelande-
Från: pangoSE 
Skickat: den 10 november 2019 14:28
Till: OpenStreetMap Sverige mailinglista 
Ämne: [Talk-se] Många nya öppna data från naturvårdsverket

Hej

All data från naturvårdsverket är CC0

https://oppnadata.se/datamangder/#esc_org=base:635/resource/9de761c624866bdca2f2e6ccdeba9815

Det finns nu följande som jag tycker vi ska börja med (förkortningarna är mina):
* kulturreservat, (NVKR)
* Naturvårdsavtal, (NVNVA)
* satellitbaserad våtmarksövervakning (som kanske kan hjälpa oss få in flera 
våtmarker) (NVVÅ)
* Data för leder och anordningar inom skyddade områden samt statliga leder i 
fjällen finns från och med V17 2018 tillgängliga enligt principen för öppen 
data. (se detaljer:
https://gpt.vic-metria.nu/data/land/Leder%20och%20friluftsanordningar%20beskrivning%20av%20%c3%b6ppna%20data.pdf)
(NVLED)
* Skyddade områden, fågeldirektivet (Natura 2000, SPA) (NVSPA)
* Skyddade områden, interimistiska förbud (i väntan på beslut om
naturreservat) (NVIF)
* Skyddade områden, biosfärsområden (NVBSF)
* Skyddade områden, naturvårdsområden (NVNV)
* Skyddade områden, biotopskyddsområden (NVBSK)
** AnderAndersson har börjat lägga in några av dessa
* Skyddade områden, naturreservat (NVNR) **(se min förre epost, det finns just 
nu 5026 NR i SE[2] som är gällande och vi har[1]:
typ rel way total
boundary=protected_area 50  0329
leisure=nature_reserve  13253546
totalt  137538755250[5])

Det finns nya WMS tjänster som saknas i JOSM. (många av dessa verkar inte 
fungera via besök i min webbläsare och jag saknar kunskap om hur vi kan få in 
detta i JOSM - vet nån annan hur vi kan få detta att funka?)

Vi skulle behöva prata om hur vi bäst gör för att få in all detta i nån 
uppdaterbar ordning och vad som är relevant för OSM.

Min uppfattning är att naturreservaten är den största datamängden, men många av 
våra reservat saknar metadatan från källdatan verkar det som.
(Se
https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/naturvardsverket_import#Boundary
för vilka key/value som vi tillämpar.)

När det gäller import så skulle jag mycket hellre lägga våra krafter på import 
av denna högkvalitetsdata ritad av människor framför den fullautomatiska NMD 
data tex som tyvärr håller låg kvalitet och nog inte är lämpad alls för import.

Jag har beskrivit här[3] hur jag kan lägga in flera på en gång så det behöver 
inte ta så lång tid alls (5 min per 10 reservat som saknas)

Min uppskattning baserad på NVNR datan och vår NR-data är att ungefär
100 reservat saknas och minst lika många är större i NVNR än i OSM.

Om du utfrån att ha läst detta vill sätta igång med NR då rekommenderar jag att 
arbeta per län och ladda ner från overpass i JOSM[4] och filtrera ut samma län 
ur NVNR med QGIS[2].

Lycka till!

mvh
pangoSE

[1] jag gjorde följande för att få fram statistik om alla våra NR:
hämtade sweden-latest.osm.pbf på geofabrik.de $ cat sweden-latest.osm.pbf |osmconvert - 
-o=swe.o5m $ osmfilter swe.o5m --keep="leisure=nature_reserve"
--keep="boundary=protected_area" >swe.nr.osm valfritt extrasteg som ökar 
hastigheten i läsning/skrivning:
konvertera från .osm -> .pbf:
$ osmconvert swe.nr.osm -o=swe.nr.osm.pbf
-> sökning i JOSM
[2] jag filtrerade via QGIS, se tidigare epost. Utav datan i NR finns följande 
protect_class=0,1,4 [3] https://www.openstreetmap.org/user/pangoSE/diary/391178
[4] https://josm.openstreetmap.de/wiki/Help/Action/Download och knappa in detta i wizard: 
boundary=protected_area or leisure=nature_reserve in "västerbottens län"
[5] Dette betyder inte att vi har med alla. Vissa av våra reservat är inte med 
i NVNR och finns kanske i .

___
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-hr] Upis podataka iz ZET-ovog GTFS-a u OSM

[Janko Mihelić]

čet, 14. stu 2019. u 11:03 Ivan Habunek  napisao je:

> Nažalost za svaku stanicu imaju samo jednu lokaciju, čak i kad su pozicije
> stajališta u raznim smjerovima dosta udaljenje.


Imaš pravo. Zato Google Maps ima na svojoj karti samo po jednu stanicu za
svaku od ovih. Pitanje je ima li smisla sada upisivati brojeve ako će se to
popraviti u nekom trenutku, onda ćemo morati sve opet upisati. A trenutno
nemamo nikakvu korist od toga.

Razmišljam da li bi se ovo dalo nekako automatizirati.
>

Za automatizaciju postoji:

https://github.com/CUTR-at-USF/gtfs-osm-sync

Java projekt koji se može bildati u mavenu. Koliko sam pročitao, može
napraviti report, i čak može automatski raditi changesetove. Što očito ne
želimo jer je ZET-ov GTFS traljav. Ali report bi mogao biti koristan.


> Da li onda ima smisla stavljati i operator=ZET na stajališta?
>

Moguće, ali vidim da se u vezi toga spominje agency_id, ali i da to radi
probleme jer jedno stajalište može koristiti više agencija. Po meni bi
operator na stajalištu značilo tko popravlja tu stanicu kada se pokvari. A
za to nisam siguran, je li to ZET ili Grad Zagreb.


> Pretraživanjem weba sam naletio na GTFS podatke za HŽ, ne znam jeste li to
> već koristili:
> https://data.gov.hr/dataset/vozni-red-h-putni-kog-prijevoza-u-gtfs-obliku


Ovaj GTFS isto nije baš detaljan, Zagrebački glavni kolodvor je jedna
točka, ništa o peronima i kolosijecima.

BTW Janko, vidio sam da ucrtavaš i popravljaš autobusne linije, da li bi
> mogao upisati što ucrtaš ovdje:
>
> https://wiki.openstreetmap.org/wiki/WikiProject_Croatia/Javni_prijevoz#Zagreb
>
> Tako se možemo lakše koordinirati.
>

Može.

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

Re: [Talk-it] iD editor

[mbranco2]

grazie Martin di averci portato a conoscenza dell'iniziativa in corso nella
comunità tedesca.
Spero che la facciano diventare una pagina wiki sottoposta a votazione,
così da tutto il mondo possiamo sottoscrivere e commentare.

Il giorno mer 13 nov 2019 alle ore 20:43 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

> Am Mi., 13. Nov. 2019 um 16:10 Uhr schrieb Stefano :
>
>> Non è nello spirito di un progetto open di ignorare e azittare le
>> critiche, al meno non lo è quando sei lo sviluppatore dell'unico editore
>> sulla pagina principale. E tanto di più quando non fai quello che vuoi tu,
>> ma quello che voglione le persone che ti pagano.
>>
>>>
>>>
>> Perché prima andava bene la do-ocracy mentre adesso si chiede la
>> dem-ocracy?
>>
>
>
> no, c'é una differenza tra do-ocracy e autocracy / oligarchia. Non puoi
> ignorare tutti gli altri, sopratutto se sei responsabile e al potere
> dell'unico editore sulla pagina principale. Non puoi chiudere ogni
> discussione (sulla cosa, portata avanti in modo civile) che non ti piaccia
> sui ticket di Github, o meglio, lo puoi fare ma vuol dire che ti sposti
> fuori da solo.
>
> Un esempio tra tanti è questo post di Bryan, dove spiega cosa non ha
> alcuna influenza sulle decisioni che fanno al riguardo del tagging:
>
> Some things that don't really factor at all into our decision:
>>
>>- how long a tag with implicit semantics has been in use
>>- how many softwares (renderers / routers or whatever) already
>>support the implicit rule
>>- how frequently the tag is used
>>- what a handful of people on a mostly dormant mailing list think
>>- what one person has written on the osm wiki
>>- how many downvotes you encourage people to put on our issue list
>>- what they are saying about us in the weekly osm tabloid
>>
>> https://github.com/openstreetmap/iD/issues/6409
>
>
> E' contro lo spirito e le regole del progetto se il numero di utilizzi di
> un tag non ha importanza. E guarda un po', basta metterlo in un preset di
> iD e dopo poco sarà utilizzato numerosamente, anche se un altro tag già
> c'era.
>
> Vi segnalo inoltre che "la communità tedesca" sta preparando un documento
> programmatico per presentare una posizione coordinata e concordata. Una
> prima bozza si trova qui:
>
>>
>> https://wiki.openstreetmap.org/wiki/User:Nakaner/Forderungen_zur_Zukunft_von_iD
>>
>> traduzione automatica:
>> Utente:Nakaner/Richieste sul futuro di iD
>> Questa è una bozza. Le modifiche sono benvenute. Per l'accordo nel forum
>> tedesco o su Talk-de è richiesto. --22:21, 12 novembre 2019 (UTC)
>>
>> Si tratta di un progetto di posizione comune della comunità tedesca
>> dell'OSM su cui votare dopo averne discusso la versione provvisoria. La
>> discussione si svolgerà nei seguenti luoghi:
>>
>> Il forum
>> Mailing list Talk-en
>>
>> Progetto: Requisiti per il futuro di iD-Editor
>>
>> L'iD-Editor è indispensabile per facilitare i principianti ad iniziare a
>> lavorare con OpenStreetMap. Gli eventi del progetto iD su GitHub e il
>> comportamento dei suoi due principali sviluppatori ci riempiono di grande
>> insoddisfazione e preoccupazione.
>>
>> I redattori online erano e sono un fastidio per molti mappatori esperti,
>> perché sono preferiti da mappatori inesperti e nuovi, che ovviamente
>> commettono errori. Tuttavia, a causa dell'inesperienza dei loro utenti e
>> del loro posizionamento come editor standard su www.openstreetmap.org, i
>> principali sviluppatori hanno una responsabilità particolare. L'editor che
>> vi viene offerto è utilizzato principalmente da mappatori nuovi e
>> inesperti. Gli errori nell'editor possono essere notati in seguito, perché
>> i mappatori più esperti usano principalmente JOSM. Come per tutti i
>> redattori popolari, le decisioni mirate a favore o contro un tag hanno una
>> grande influenza sui dati - e questo in un progetto in cui i tag prevalgono
>> regolarmente sugli altri perché sono votati con i piedi (cioè l'uso dei
>> tag).
>>
>> Infatti, le richieste di mappatori esperti sugli editor online sono
>> elevate - troppo elevate a seconda del proprio punto di vista - e gli
>> errori dei nuovi arrivati sono spesso attribuiti anche agli sviluppatori. I
>> mappatori più anziani ricordano nei forum e sulle mailing list discussioni
>> senza fine sulle carenze dell'editor iD nel trattare le relazioni. Da
>> questo punto di vista l'editore non è in alcun modo inferiore al suo
>> predecessore Potlatch ed ha difficoltà ad essere apprezzato da mappatori
>> esperti.
>>
>> L'annuncio di qualche mese fa che iD dovrebbe ottenere un validatore ha
>> suscitato la speranza che l'editore farà più giustizia al suo compito.
>> Tuttavia, queste speranze non sono state soddisfatte. Al contrario, invece
>> di riconoscere ed evitare gli errori tipici degli utenti in modo
>> responsabile, cauto e prudente, i principali sviluppatori stanno
>> spudoratamente sfruttando la loro posizione di potere per la propria agenda.
>>
>> Anche 

Re: [Talk-hr] Upis podataka iz ZET-ovog GTFS-a u OSM

[Ivan Habunek]

On Thu, 14 Nov 2019, at 10:39, Janko Mihelić wrote:
> GTFS (General Transit Feed Specification) je otvoreni standard za opis
> podataka pojedinog javnog prijevoznika. Unutra su opisane sve stanice,
> rute, vremena kretanja, itd.

Primjetio sam da ovo postoji i super da postoji. :) Nažalost za svaku stanicu 
imaju samo jednu lokaciju, čak i kad su pozicije stajališta u raznim smjerovima 
dosta udaljenje. Na primjer za ovu stanicu sam ručno unio 3 lokacije, a samo je 
jedan set koordinata u GTFS: https://overpass-turbo.eu/s/O5i

> Ono što tu ima a meni se čini da bi trebali upisati u OSM su ref-ovi
> (id-ovi) stanica u datoteci stops.txt. Predlažem tag ref=*, zbog
> jednostavnosti. Ref-ove ruta već imamo jer su u GTFS-u identični broju
> pojedine linije.

Ovo je dobra ideja, slažem se, mada je ekstra posla. Razmišljam da li bi se ovo 
dalo nekako automatizirati.
Da li onda ima smisla stavljati i operator=ZET na stajališta?

> Trebalo bi pogledati ima li još koji hrvatski prijevoznik sa GTFS-om.

Pretraživanjem weba sam naletio na GTFS podatke za HŽ, ne znam jeste li to već 
koristili:
https://data.gov.hr/dataset/vozni-red-h-putni-kog-prijevoza-u-gtfs-obliku

BTW Janko, vidio sam da ucrtavaš i popravljaš autobusne linije, da li bi mogao 
upisati što ucrtaš ovdje:
https://wiki.openstreetmap.org/wiki/WikiProject_Croatia/Javni_prijevoz#Zagreb

Tako se možemo lakše koordinirati.

Pozdrav
Ivan

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

[Talk-it] Tagging scheme alimentare

[Cascafico Giovanni]

Ciao a tutti,
dovo aver un po' rotto sul gruppo Telegram, per evitare di perdere gli
apporti scrivo qua.

In vista di un import relativo al comparto alimentare mi trovo davanti
alle etichettature. Si tratta di assegnare delle chiavi e valori ad
attività come prosciuttifici, norcini, catering e gastronomie ecc.
Molti elementi del dataset non hanno la rivendita, per cui escludo la
chiave shop. Per il resto...

- man_made si riferisce alla struttura fisica e non all'attività
- industrial si riferisce all'uso del suolo (slaughterhouse è
wikizzato solo su industrial)

Deduco quindi che resti man_made=works [1] e craft [2] ...La wiki poi
apre un dubbio sui volumi di lavorazione/produzione che dovrebberio
discriminare tra

craft=meat|beer|dairy| ecc...

oppure la coppia
man_made=works
product=meat|beer|dairy| ecc...

IMHO sarei propenso per craft, perchè definisce con un solo tag, poi
perchè  la fonte dei dati è confartigianato (e no confindustria) ed
infine perchè la wiki discrimina in modo soggettivo ("small
amounts...")

[0] https://wiki.openstreetmap.org/wiki/Import/Catalogue/AlimentareFVG
[1] https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dworks
[2] https://wiki.openstreetmap.org/wiki/Key:craft

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

Re: [Talk-it] iD editor

[Federico Cortese]

On Wed, Nov 13, 2019 at 8:43 PM Martin Koppenhoefer
 wrote:
>
> Che dite, vogliamo appoggiare l'idea? Attualmente è ancora molto "fresco" (da 
> modificare, è la prima bozza), ma la direzione sarà probabilmente quella, 
> attualmente c'è la discussione in talk-de e forum.

Grazie Martin per questa segnalazione.
Concordo pienamente col documento da te condiviso, quindi sarei molto
favorevole alla sottoscrizione come comunità italiana.

Ciao,
Federico

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

[Talk-hr] Upis podataka iz ZET-ovog GTFS-a u OSM

[Janko Mihelić]

Pozdrav!

GTFS (General Transit Feed Specification) je otvoreni standard za opis
podataka pojedinog javnog prijevoznika. Unutra su opisane sve stanice,
rute, vremena kretanja, itd.. Našao sam da je ZET objavio svoj GTFS, ovdje:

http://www.zet.hr/odredbe/datoteke-u-gtfs-formatu/669

Ono što tu ima a meni se čini da bi trebali upisati u OSM su ref-ovi
(id-ovi) stanica u datoteci stops.txt. Predlažem tag ref=*, zbog
jednostavnosti. Ref-ove ruta već imamo jer su u GTFS-u identični broju
pojedine linije.

Ako OsmAnd ili netko drugi ikad krene uzimati GTFS podatke, bit ćemo
spremni :)

Trebalo bi pogledati ima li još koji hrvatski prijevoznik sa GTFS-om.

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

Re: [OSM-talk-fr] Affiner la sortie de mes requêtes Overpass

[Etienne Trimaille]

Le jeu. 14 nov. 2019 à 08:36, Jean-Christophe Becquet  a
écrit :

>  - une couche avec une seule géométrie qui couvre tous le parcours de
> l'itinéraire
>
> C'est cette dernière que je voudrais récupérer dans uMap. C'est à dire
> que lorsque j'importe l'itinéraire, il crée une seule ligne dans mon
> calque et pas autant de lignes que la relation contient de tronçons.
>
> Je ne sais pas s'il est possible de récupérer ça directement avec
> Overpass ou si QuickOSM fait un post traitement.
>

QuickOSM ne fait pas vraiment un post-traitement. Il découpe juste par type
de géométrie.
La dernière dont tu parles, c'est la relation OSM, de type multilinestrings.
-

*multilinestrings* : “relation” features that form a multilinestring(type =
‘multilinestring’ or type = ‘route’).
d'après la documentation OGR.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Affiner la sortie de mes requêtes Overpass

[Cyrille37 OSM via Talk-fr]

Salut

Le 14/11/2019 à 08:35, Jean-Christophe Becquet a écrit :

http://overpass-turbo.eu/s/O4N
Non, ou alors c'est moi qui m'y prend mal.

Lorsque j'exécute cette requête dans QuickOSM, je récupère 3 couches
dans QGIS :

  - une couche avec les ways
  - une couche avec les points
  - une couche avec une seule géométrie qui couvre tous le parcours de
l'itinéraire

Je ne sais pas s'il est possible de récupérer ça directement avec
Overpass ou si QuickOSM fait un post traitement.


Regarde le résultat dans l'onglet "Données" d'Overpass-turbo, il y a 
bien qu'un seul élément xml.


Cyrille37.

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