[Talk-in] Reg: OSM India conference

[Asish Abraham Joseph]

Hey all,

Greetings from Kerala. In light of discussion we had at SotM Asia 2019,
Saikat Maiti mentioned why shouldn't we host an annual OSM conference in
India. I wish to know your opinions on starting an OSM India conference.

With Regards,


Asish Abraham Joseph
T: +919495003572
E: asishabrahamjos...@gmail.com
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [OSM-legal-talk] use OSM data to select proprietary data

[Mateusz Konieczny]

13 Dec 2019, 19:28 by legal-talk@openstreetmap.org:

> Hi Frederik,
>
> Here's why I disagree. The meaning of "derived" in a colloquial sense and the 
> definition of "Derivative Database" are not the same.
> While colloquially, it may be fair to interpret "derived" as "made from" or 
> "could not have been made without", that is not the legal definition of 
> "Derivative Database".
>
> From ODbL:
> “Derivative Database” – Means a database based upon the Database, and
> includes any translation, adaptation, arrangement, modification, or any
> other alteration of the Database or of a Substantial part of the
> Contents. This includes, but is not limited to, Extracting or
> Re-utilising the whole or a Substantial part of the Contents in a new
> Database.
>
> So a Derivative Database must include a "translation, adaptation, 
> arrangement, modification, or any other alteration of the Database or of a 
> Substantial part of the
> Contents." In other words, it has to include in the new database at least a 
> substantial part of what was in the previous database.
>
Can you point me to legal definition
of "substantial part"?

I would expect that extracting boundary
data for locations is some other database
would count as "substantial part".

But maybe this loophole actually works
if "substantial" is defined to be unreasonably high.
> The inference of "with pubs" would not be, in my mind, a "translation, 
> adaptation, arrangement, modification, or any other alteration of the 
> Database or of a Substantial part of the
> Contents" because it is too minor of an inference.
>
It is certainly translation/adaptation,
but such use may pass as not
"substantial".

I hope that "not substantial" would
work for something like 

(1) not repeated 
extraction of location data for 100 points,
but I would be happy to be pointed to an
unbiased legal analysis of this term.

(2) not repeated extraction of boundaries
from OSM with no more than 100 nodes
in total

but it is hard to be to guess what can
be considered as substantial.
Probably depends on a lawyer and who
pays them to write a legal decision.
> With respect to Mateusz's more extreme example, this is also very 
> specifically covered in the Geocoding Guidelines: "> A collection of 
> Geocoding Results will be considered a systematic attempt to aggregate data 
> if it is used as a general purpose geodatabase, regardless of how the 
> original aggregation was accomplished."
>
> In other worse, if, as in Mateusz's hypothetical, you attempt to abuse the 
> system to reverse engineer a database that is equivalent to OSM, you make a 
> Derivative Database. But Mattias has been very clear that is not what he's 
> doing. He just wants to display the subparts of a list of points he already 
> has on a different layer than the other subparts. 
>
I thought that it was claimed that it
is not translation/adaptation - but
given that argument relies on 
"substantial" part then my example is
not applicable.___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [talk-au] 1300 / 1800 phone number format

[Graeme Fitzpatrick]

On Sat, 14 Dec 2019 at 14:34, Kim Oldfield 
wrote:

>
> My suggested rewrite is:
>

Thanks, Kim - that sounds much better!

Please go ahead & make the change :-)

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

Re: [talk-au] 1300 / 1800 phone number format

[Kim Oldfield]

On 14/12/19 2:03 pm, Graeme Fitzpatrick wrote:


Thanks for confirmation, fellas

On Sat, 14 Dec 2019 at 12:03, Phil Wyatt > wrote:



I think an Aus Wiki update would be a good thing.


Done!

https://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines#13.2C_1300.2C_1800_and_1900_numbers

As always, comments welcomed :-)


The entry is now confusing, initially suggesting phone=, and later it 
says to change it to phone:AU=


My suggested rewrite is:

13, 1300, 1800 and 1900 numbers cannot be called from overseas so should 
be entered using the phone:AU= tag. eg phone:AU=1800 xxx xxx


Using phone:AU= is preferred over phone= as it suits international 
format requirements 
https://wiki.openstreetmap.org/wiki/Key:phone#Support_for_multiple_countries, 
and prevents Osmose / Map Roulette "errors"*.*


If the business has another standard number e.g. for local calls or 
calls from overseas, enter it as phone= in normal international 
formatting (+61 x  ).





Thanks

Graeme

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


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

Re: [talk-cz] Svatojakubska cesta - SK

[gorn]

Dobrý den,

Mapováním Svatojakubské cesty se dlouhodobě zabývám, můžu tedy případně pomoci. 
Sním se zeptat z jakých zdrojů je přiložené vedení cesty a jak jecunavení v 
terénu (a jak jednotně). Toto je naopř v ČR dost problém.

Díky gorn

⁣Odesláno z BlueMail ​

26. 11. 2019 13:42, 13:42, "Petr Voldán"  napsal/a:
>Ahoj,
>
>mám pocit, že se v komunitě někdo speciálně věnuje Svatojakubske cestě.
>
>Napsali nám ze Slovenska
>
>> Dobrý deň,
>>
>> Naše občianske združenie sa venuje značeniu a rozvoju Svätojakubskej
>> cesty na Slovensku, známej ako Camino de Santiago.
>>
>>
>> Radi by sme nahrali našu 700 km dlhú trasu do locusmap. Ako by sme
>> mali postupovať?
>>
>>
>> Ďakujem za informácie.
>>
>>
>> Eva Kocanová
>>
>>
>> Priatelia svätojakubskej cesty na Slovensku - Camino de Santiago,
>o.z.
>>
>> Email: i...@caminodesantiago.sk
>>
>Mohl bych Vás požádat o info, kam mohu paní odkázat ?
>
>Díky Petr V.
>
>
>
>
>
>___
>talk-cz mailing list
>talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz
>https://openstreetmap.cz/talkcz
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-au] 1300 / 1800 phone number format

[Graeme Fitzpatrick]

Thanks for confirmation, fellas

On Sat, 14 Dec 2019 at 12:03, Phil Wyatt  wrote:

>
> I think an Aus Wiki update would be a good thing.
>

Done!

https://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines#13.2C_1300.2C_1800_and_1900_numbers

As always, comments welcomed :-)

Thanks

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

Re: [talk-au] 1300 / 1800 phone number format

[Andrew Harvey]

This sounds good to me.

On Sat, 14 Dec 2019 at 12:42, Graeme Fitzpatrick 
wrote:

> Just opened a Map Roulette challenge for phone numbers not being in the
> "correct" format.
>
> The first one that came up was a local Dan Murphy's with it's number
> entered correctly as 1300 723 388, which has apparently errored because of
> this
> https://wiki.openstreetmap.org/wiki/Key:phone :
> "Also some amenities have a local phone number which can only be used
> domestically not cannot be called internationally (notably for toll free
> phone numbers, or abbreviated phone numbers). For example:
>
>- phone:FR=0 800 123 456 for standard toll free call only from France
>where the amenity is (note that there's NO "+" sign, it is NOT in
>international format),"
>
>
> Our Oz guidelines
>
> https://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines#1300.2C_1800_and_1900_numbers
>  say
>
> "1300 and 1800 and 1900 numbers cannot be called from overseas so should
> simple be entered as they are. Some 1800 numbers give another number for
> calls from overseas. It may be best to put in the local number, no codes."
>
> So, should we start entering *phone:AU=1300 xxx xxx*, & also amend our
> guidelines?
>
> Thanks
>
> Graeme
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-legal-talk] use OSM data to select proprietary data

[Kathleen Lu via legal-talk]

Nuno -
I do not see how Matthias's usecase qualifies as "AND you have *added to or
enhanced our data*" since the houses and flat and their prices are *not*
added to OSM houses or flats, but if this FAQ answer is misleading, we
should rewrite this FAQ answer to more accurate reflect ODbL.

On Fri, Dec 13, 2019 at 11:45 AM Nuno Caldeira 
wrote:

> well
> https://wiki.osmfoundation.org/wiki/Licence/Licence_and_Legal_FAQ#The_OpenStreetMap_Geodata_Licence
>
> Secondly, you *"Share Alike"*. If you do not make any changes to
> OpenStreetMap data, then you are unlikely to have a "Share Alike"
> obligation. But, if you *publicly distribute something that you have made*
> from our data, such as a *map or another database*, AND you have *added
> to or enhanced our data*, then we want you to make those additions
> publicly available. We obviously prefer it if you added the data straight
> back to our database, but you do not have to, *as long as the public can
> easily get a copy of what you have done.* If you do not publicly
> distribute anything, then you do not have to share anything.
>
>
> Às 19:34 de 13/12/2019, Kathleen Lu via legal-talk escreveu:
>
> Nuno - I think you are operating under the mistaken assumption that a
> CC-BY-SA license would mean that uses such as Mattias's would require
> sharealike.
>
> Here's CC-BY-SA's definition of a Derivative Work:
> *"Derivative Work"* means a work based upon the Work or upon the Work and
> other pre-existing works, such as a translation, musical arrangement,
> dramatization, fictionalization, motion picture version, sound recording,
> art reproduction, abridgment, condensation, or any other form in which the
> Work may be recast, transformed, or adapted, except that a work that
> constitutes a Collective Work will not be considered a Derivative Work for
> the purpose of this License. For the avoidance of doubt, where the Work is
> a musical composition or sound recording, the synchronization of the Work
> in timed-relation with a moving image ("synching") will be considered a
> Derivative Work for the purpose of this License.
>
> Here's CC-BY-SA's definition of a Collective Work:
> *"Collective Work"* means a work, such as a periodical issue, anthology
> or encyclopedia, in which the Work in its entirety in unmodified form,
> along with a number of other contributions, constituting separate and
> independent works in themselves, are assembled into a collective whole. A
> work that constitutes a Collective Work will not be considered a Derivative
> Work (as defined below) for the purposes of this License.
>
> As you can see from these examples (which focus on creative derivatives,
> since facts are not even copyrightable in the US and there is no US
> database protection law), a "derivative work" needs quite a bit of the
> original to qualify. The meaning of a "derivative work" was always much
> narrower than what a colloquial understanding of what "derived" might be,
> and the change in license did not change that.
>
> -Kathleen
>
>
>
> On Fri, Dec 13, 2019 at 11:11 AM Nuno Caldeira <
> nunocapelocalde...@gmail.com> wrote:
>
>> these new Liberal interpretation of ODbL are funny. to bad it's not
>> documented what we wanted when we changed license. seems to be full of
>> lies
>>
>>
>> https://wiki.osmfoundation.org/wiki/Licence/Historic/We_Are_Changing_The_License
>>
>> *"This means that “good guys” are stopped from using our data but the
>> “bad guys” may be able to use it anyway." *
>>
>> *" We believe that a reasonable consensus has been built that our current
>> progress should be to maintain a Share-Alike license (see more below) but
>> have it written explicitly for data."*
>>
>> *"Both licenses are “By Attribution” and “Share Alike”." *
>>
>> *"But what happens if the Foundation is taken over by people with
>> commercial interests?*
>>
>>- *You still own the rights to any data you contribute, not the
>>Foundation. In the new Contributor Terms, you license the Foundation to
>>publish the data for others to use and ONLY under a free and open 
>> license.*
>>
>>
>>- *The Foundation is not allowed to take your contribution and
>>release it under a commercial license.*
>>
>>
>>- *If the Foundation fails to publish under only a free and open
>>license, it has broken its contract with you. A copy of the existing data
>>can be made and released by a different body.*
>>
>>
>>- *If a change is made to another free and open license, it is active
>>contributors who decide yes or no, not the Foundation."*
>>
>>
>>
>> On Fri, 13 Dec 2019, 18:56 Frederik Ramm,  wrote:
>>
>>> Hi,
>>>
>>> On 13.12.19 19:28, Kathleen Lu via legal-talk wrote:
>>> > “Derivative Database” – Means a database based upon the Database, and
>>> > includes any translation, adaptation, arrangement, modification, or any
>>> > other alteration of the Database or of a Substantial part of the
>>> > Contents.
>>>
>>> Interesting. I knew the ODbL text but I have always 

Re: [OSM-legal-talk] use OSM data to select proprietary data

[Kathleen Lu via legal-talk]

Hi Christoph,
I think that there is a premise to your list that I do not quite agree
with. ODbL says:

3.1 Subject to the terms and conditions of this License, the Licensor
grants to You a worldwide, royalty-free, non-exclusive, terminable (but
only under Section 9) license to Use the Database for the duration of
any applicable copyright and Database Rights. These rights explicitly
include commercial use, and do not exclude any field of endeavour. To
the extent possible in the relevant jurisdiction, these rights may be
exercised in all media and formats whether now known or created in the
future.

So the rights granted are *all* database and copyright rights, subject to
certain conditions that apply to Produced Works and Derivative Databases.
There are rights that are completely not covered by ODbL are trademark and
patent rights, which would be #6.
But that also means there is a category #7 you have not listed, where the
database and/or copyright rights *are* conveyed by ODbL and no limitations
on the exercise of those rights is placed on the user.
So as far as usecases like Matthias's which we are discussing, my opinion
is that it is #5, but if it is not, it could be #7. But it could not be #6.



On Fri, Dec 13, 2019 at 11:54 AM Christoph Hormann 
wrote:

> On Friday 13 December 2019, Frederik Ramm wrote:
> >
> > I had until now assumed that such works would definitely fall under
> > the ODbL but you are right, they don't really fit the "Derivative
> > Database" definition.
>
> My reading of the ODbL has always been that something is either
>
> 1) the original Database (or substantial parts of it)
> 2) a Derivative Database
> 3) a Collective Database
> 4) a Produced Work
>
> or if something is neither of these it would be either
>
> 5) something that is not protected by law at all so free to use
> independent of the license terms (like insubstantial extracts of data).
> 6) something the ODbL does not grant any rights for and therefore cannot
> be legally used by the user based on the ODbL.
>
> So my question would always be if someone considers certain things not
> to be a Derivative Database which of the five other above cases applies
> instead.
>
> I would kind of assume that for case (5) there are probably already some
> court rulings available for to what extent EU database protection
> applies to set operations of different databases since this is nothing
> specific to spatial databases but also is relevant for many other types
> of data.
>
> As i already wrote in
>
> https://lists.openstreetmap.org/pipermail/talk/2019-November/083535.html
>
> existing OSMF community guidelines suggest spatial operations like
> ST_Difference() and ST_Intersection() yield Derivative Databases that
> are subject to share-alike.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-talk-fr] ref:FR:FANTOIR

[Jérôme Amagat]

Le sam. 14 déc. 2019 à 01:38, Jérôme Amagat  a
écrit :

>
>
> Le ven. 13 déc. 2019 à 22:55,  a écrit :
>
>> Et d'autres ont été actifs ailleurs : actuellement toutes les clés sont à
>> 11 chiffres (ou 11, un point-virgule et 11).
>>
> Tu te trompes, il en reste plein, tu n'as pas modifié la bonne requête, ça
> donne ça :
> https://overpass-turbo.eu/s/OXy
>
> et même plus précis :
> https://overpass-turbo.eu/s/OXB
>

J'ai mis l'expression régulière utilisée, là :
https://wiki.openstreetmap.org/wiki/Item:Q600
et j'ai ajouté une phrase sur le wiki dès le début de la page pour dire
qu'il faut 10 caractères :
https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ref:FR:FANTOIR

[Jérôme Amagat]

Le ven. 13 déc. 2019 à 22:55,  a écrit :

> Et d'autres ont été actifs ailleurs : actuellement toutes les clés sont à
> 11 chiffres (ou 11, un point-virgule et 11).
>
Tu te trompes, il en reste plein, tu n'as pas modifié la bonne requête, ça
donne ça :
https://overpass-turbo.eu/s/OXy

et même plus précis :
https://overpass-turbo.eu/s/OXB
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-at] Windy Map

[Kevin Kofler]

Rudolf Mayer wrote:
> Ja, die anderen Menüpunkte rechts oben neben den icons sind nicht
> sonderlich sichtbar, aber hier wird die Attribution in einer Lücke
> dargestellt, auf der man nichts *vermuten* würde, das ist so am
> Bildrand, da sieht man nichts. Selbst wenn es dort in sattem schwarz
> stehen würde, man würde es wohl leicht übersehen..

Die untere rechte Ecke wird aber von https://www.openstreetmap.org/copyright 
ausdrücklich vorgeschlagen bzw. fast schon gefordert. Und alle Web-Karten, 
die ich kenne, haben den Urheberrechtshinweis dort.

Was die Lesbarkeit des Textes betrifft: Auf den niedrigeren Zoomstufen, wo 
die Windstärke noch farbig hinterlegt ist, kann man ihn sehr gut lesen. Aber 
gerade dann, wenn man wirklich viel von der OSM sieht (bei höheren 
Zoomstufen, wo dann die Einfärbung auf einmal aufhört), auf einmal nicht 
mehr, weil der Hintergrund ohne die Einfärbung viel heller wird.

Ansonsten finde ich die Windy Map ja gar nicht so schlecht, vor allem im 
Vergleich mit der Konkurrenz. Immerhin verwenden sie OSM! Und als Greta 
Thunberg mit dem Segelboot über den Atlantik und zurück unterwegs war, hatte 
ich den direkten Vergleich:

Bei der Hinreise war der Tracker auf Windy Map, da konnte man nicht nur den 
aktuellen Wind sehen, sondern auch die Vorhersagen für die ganze Welt, 
kostenlos und ohne Registrierung. So war es auch gut nachzuvollziehen, warum 
die Crew jetzt das Segel so gedreht hat, daß das Boot in eine Richtung 
steuert und nicht in eine andere. (Meistens war in der "anderen" Richtung 
entweder ein Unwetter oder eine totale Flaute.) Und das Zoomen funktionierte 
einwandfrei. Und die Grafik funktionierte sogar auf einem e-Book-Reader in 
dessen Browser, wenn auch sehr langsam, und durch die Animationen natürlich 
nicht sehr e-Paper-freundlich (viel Flickern).

Bei der Rückreise mit einem anderen Team war der Tracker hingegen beim 
angeblichen "Marktführer" für Windvorhersagen, den ich hier wirklich nicht 
bewerben will. (Der verwendet ja nicht einmal OSM, sondern G* Maps.) 
Dort konnte man nur die aktuelle Windsituation (keine Vorhersagen) in einem 
(relativ großen, aber doch) Quadrat (in der Projektion der Karte) rund um 
die aktuelle Position des Bootes sehen. Die haben natürlich die Vorhersagen, 
wollen sie aber offenbar nur zahlenden Kunden zeigen (selbst die Modelle 
ECMWF und GFS, die auf der Windy Map auch verfügbar sind – ECMWF scheint bei 
beiden der Default zu sein). Außerdem klappte auch das Zoomen oft nicht, die 
Winde waren auf einmal weg. Ich habe mir dann so beholfen, daß ich die 
Koordinaten des Bootes in die Windy Map kopiert habe und dort die 
Vorhersagen angeschaut habe. Und auf dem e-Book-Reader ging die Webseite des 
"Marktführers" überhaupt nicht.

Trotzdem ist es natürlich sehr ärgerlich, daß die Windy Map die Attribution 
nicht so hinbekommt, daß man sie in jedem Kontext lesen kann.

Kevin Kofler


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

Re: [OSM-talk-fr] Élections au board de la Fondation OSM

[osm . sanspourriel]

N'oubliez pas de voter avant ce samedi 17 h et de préférence bien avant.
Visez demain midi au plus tard !

Comme l'an dernier, Christoph a bien résumé la situation.

Attention : c'est un scrutin à vote unique transférable


Donc même avec quatre postes on peut donner jusqu'à 12 voix.

Mais il vaut mieux donner 0 à ceux que vous voulez bannir.

Comme tous ceux qui se sont exprimés sur les liens dégotés par Vincent
et cie, je déconseille vivement les inféodés à des entreprises non
sensibles à la communauté et sensibles aux intérêts de leurs entreprises
pensant au mieux à la communauté comme des gens travaillant gratuitement
pour eux :

 * Jinal
 * Mikel
 * Steve
 * Michal

Donc en fait 8 voix c'est un maximum.

Je peux donner ma préférence en MP. Elle comprend aussi des personnes
travaillant pour des sociétés gravitant autour d'OSM mais (et)
respectant l'écosystème. Et si vous avez un avis, n'hésitez pas à me le
donner.

Sans oublier le vote sur les status.

Jean-Yvon

Le 12/12/2019 à 11:27, Christine Karch - christ...@hermione.de a écrit :

Il y a aussi les changements en articles d'association. Recommandation
de Simon Pool est "yes" pour tous les trois changements ...

Am 12.12.19 um 09:42 schrieb thevenon.jul...@free.fr:

- Mail original 
De: "Vincent Bergeot" 
À: talk-fr@openstreetmap.org
Envoyé: Lundi 9 Décembre 2019 10:15:12
Objet: [OSM-talk-fr] Élections au board de la Fondation OSM


Bonjour,
Vote à la fondation jusqu'au 14 décembre (2019-12-14 16:00 UTC ) pour les 
votant(-e)s et pour la curiosité des autres :
  * l'ensemble des réponses et des manifestes (en anglais) : 
https://wiki.openstreetmap.org/wiki/Foundation/AGM19/Election_to_Board/Answers_and_manifestos
Des analyses et propositions de votes :
* 
http://blog.imagico.de/2019-osmf-board-candidates-analysis-and-recommendations/
* https://wiki.openstreetmap.org/wiki/User:Westnordost/AGM19_Cheatsheet
* https://www.openstreetmap.org/user/SJFriedl/diary/391453

Hello,

Petit rappel pour ceux qui ont recus les bulletins mais qui n auraient pas 
encore votes !
Pour les autres n hesitez pas a lire les manifestes des candidats ou l analyse 
de Christoph Hormann ( 
http://blog.imagico.de/2019-osmf-board-candidates-analysis-and-recommendations/ 
), ca illustre bien les enjeux de l election

Julien

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



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

Re: [OSM-legal-talk] use OSM data to select proprietary data

[Michael Patrick]

There are other writings about ODBL, but this one captures the issues
fairly well:
https://wiki.openstreetmap.org/wiki/ODbL_comments_from_Creative_Commons , a
more in depth treatment can be found in ' Safe to be Open: Study on the
protection of research data and recommendation for access and usage ':
https://www.fosteropenscience.eu/sites/default/files/pdf/835.pdf

Whether it is government, commercial interest or academic researchers, IMHO
it is almost inevitable that 'mixing' will occur as information flows
downstream and back upstream among federated sources. Until somebody
develops and deploys some sort of blockchain provenance that can be
attached to each DB element to keep track of things through pipelines of
analysis/extract transformations, despite the best intentions of data
consumers, it is impossible to be ODBL compliant except in the very
simplest cases, like displaying the end map (with attribution) or using
exclusively ODBL data.

To some extent, extremely permissive licenses ( or 'license free' like the
US Federal ) allow data to easily flow into ODBL, but ironically that
benefit can not be reciprocated. While the https://opendatacommons.org/
seems to be stagnant since 2010 ( last  'News' post, and the Advisory
Council page links mostly go to 404 ) , in contrast the Creative Commons
organization has been continually evolving and adapting.

For me, the point selection via ODBL polygons creates ODBL data.

Michael Patrick
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [talk-cz] Promítnutí změn v OSM nebo chyba editace?

[Marián Kyral]

Ahoj,

na https://hiking.waymarkedtrails.org/#?map=16!50.4123!16.3362 to vidím
myslím správně. Buď se to aktualizovalo dnes, nebo máš v keši prohlížeče
starší verzi dlaždic na osmap.cz. Zkus vynutit refresh přes Ctrl+R.




To, že to ještě není na seznamu nemusí nic znamenat. Jejich proces
aktualizace je složitější (správné napojení na jejich CZ/SK data)  a
vyžaduje více času, takže neaktualizují denně. Klidně to může trvat i měsíc.




Marián

-- Původní e-mail --
Od: Radek Papež 
Komu: talk-cz@openstreetmap.org
Datum: 13. 12. 2019 21:01:52
Předmět: [talk-cz] Promítnutí změn v OSM nebo chyba editace?
"
Zdravím,



před třemi týdny jsem provedl úpravu vedení turistické trasy v polském
příhraničí, červená trasa ve skutečnosti totiž vede přímo přes vrchol
Grodczyn

sada změn zde: https://www.openstreetmap.org/changeset/77389905
(https://www.openstreetmap.org/changeset/77389905) 





Zajímalo by mne, zda jsem v něčem neudělal chybu, neboť na OSM.cz ve vrstvě
„Cyklo+Turistická (EU)“ červená trasa stále vede okolo vrcholu, jakoby žádná
úprava neproběhla:


https://openstreetmap.cz/#map=16/50.4139/16.3321=m
(https://openstreetmap.cz/#map=16/50.4139/16.3321=m) 




Podobně je to na Mapy.cz, které v zahraničí přebírají mapy z OSM, taktéž
beze změny:

https://mapy.cz/s/derupuhute(https://mapy.cz/s/derupuhute) 





Je potřeba ještě něco udělat, nebo stačí jen vyčkat (a jak dlouho) na
aktualizaci mapových dlaždic?




Díky

Radek

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

Re: [OSM-talk-fr] ref:FR:FANTOIR

[osm . sanspourriel]

Et d'autres ont été actifs ailleurs : actuellement toutes les clés sont
à 11 chiffres (ou 11, un point-virgule et 11).

Vous ne m'en avez même pas laissé un.

Merci à Jérôme pour avoir débusqué les lièvres et à tous les chasseurs.
Ne pas détourner cette phrase de son contexte^^.

Jean-Yvon

Le 13/12/2019 à 14:07, Xavier BIZOT - xavierbizot22...@gmail.com a écrit :

Bonjour,

Le peu d'erreurs sur la Bretagne ont été corrigé de mon côté :)

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

Re: [OSM-talk-fr] ref:FR:FANTOIR

[Philippe Verdy]

La. N'est toi qui détourne la conversation, on parle bien du FANTOIR de la
DGFIP, pas du COG de l'INSEE (cf le titre de ce fil)


Le ven. 13 déc. 2019 à 17:12, deuzeffe  a écrit :

> Je te parle des codes communes pour lesquels tu n'as donné aucune
> référence fiable et validée. Ne détourne pas la conversation steuplé.
>
> Le 13/12/2019 à 05:30, Philippe Verdy a écrit :
> > Ne me fais pas croire que le FANTOIR est décrit dans le COG, même en
> 2019.
> > Là c'est toi qui confond, ce n'est même pas la même source (et il n'y a
> > pas de synchro directe entre les deux, toujours des décalages)!
> >
> > COG: source INSEE (https://www.insee.fr/fr/information/2016807)
> > FANTOIR: source DGFIP
> > (
> https://www.data.gouv.fr/fr/datasets/fichier-fantoir-des-voies-et-lieux-dits/
> )
> >
> > Je sais faire la différence merci.
> >
> > Le FANTOIR utilise des codes communes complets à 6 chiffres (3 pour le
> > département métropole+direction ou pour les DOM; puis 3 pour la commune
> > même dans les DOM, mais pas synchronisé immédiatement et partour avec le
> > COG du même millésime), après le code RIVOLI du type de voie (1 lettre),
> > et avant le numéro de voie sur 4 chiffres (unique par code RIVOLI plus
> > code commune à 6 chiffres); le dernier caractère est une lettre-clé
> > calculée sur les 11 caractères précédents (code RIVOLI du type de voie,
> > département+direction+commune, numéro de voie)
> >
> > Bref les codes commune complets du COG et ceux du FANTOIR sont
> > différents en forme et en usage même si à l'origine le FANTOIR a basé
> > ses codes commune sur le code INSEE des commune issu du COG. Le COG n'a
> > aucun "code direction" et réduit les codes communes de 3 à 2 chiffres
> > dans les DOM en ajoutant un chiffre au département.
> >
> > On peut se passer de la lettre clé finale (après la lettre RIVOLI et les
> > 6+4 chiffres) dans la base (elle n'ajoute aucune précision, c'est juste
> > une vérification).
> >
> > Si on réduit le code commune complet de 6 chiffres à 5 chiffres, la
> > lettre clé finale n'est plus correcte, mais quoi qu'il en soit elle
> > n'est toujours pas identifiante mais permet de déduire le chiffre
> > manquant dans le code commune complet à 6 chiffres).
> >
> > Des corrections semi-automatiques sont possibles selon la forme trouvée:
> > - 4 chiffres plus 1 lettre : il manque la commune (requête géographique
> > semi-automatique); la lettre clé finale est présente, on peut en déduire
> > le code RIVOLI initial du type de voie grace à la lettre-clé finale
> > après avoir déduit la commune, mais problème dans les départements ayant
> > plusieurs directions, car alors on aura plusieurs codes RIVOLI de type
> > de voie déduits et on ne peut pas choisir (correction donc manuelle, le
> > code direction n'est pas forcément 0 à Paris, dans le Nord, dans le
> > Rhône ou les Bouches-du-Rhône, mais les directions sont des secteurs
> > géographiques dans un département, on s'en sort donc).
> > - 4 chiffres: on ne peut rien faire, il manque la lettre code RIVOLI
> > initiale pour le rendre unique, cas d'erreur.
> > - 1 lettre plus 4 chiffres : il manque les 6 chiffres du code
> > département+direction+commune FANTOIR, puis la lettre-clé calculable. On
> > peut cherche la commune par requête géographique (à confirmer, attention
> > aux pièges des communes fusionnées, il peut y avoir encore plusieurs
> > codes possibles car pas de synchro immédiate du FANTOIR avec le COG).
> > - 1 lettre plus 10 chiffres : il manque juste la lettre clé finale
> > calculable automatiquement.
> >
> >
> > Le jeu. 12 déc. 2019 à 22:56, deuzeffe  > > a écrit :
> >
> > Ne me fais pas croire que tu ne sais pas trouver les pages qui
> > décrivent
> > très précisément le COG et tous les champs. C'est sûr que c'est moins
> > facile de trouver le dernier COG du printemps-été 2019 avec toutes la
> > liste de toutes les communes et leur identifiant unique que de
> peigner
> > la girafe, mais quand même.
> >
> > Bref.
> >
> > Le 12/12/2019 à 22:49, Philippe Verdy a écrit :
> >  > Le COG ne répond pas à ça concernant le FANTOIR, et les codes
> > communes
> >  > ne sont pas si uniques que ça (il y a tout un historique lié aux
> >  > fusions/défusions, et réaménagement de frontières communales ou
> >  > réaffectations de voies limitrophes) ! Le définition des tues est
> > une
> >  > compétence communale, mais comme les communes changent aussi, ce
> > n'est
> >  > pas en passant à l'échelle départementale avec le COG actuel qu'on
> >  > résoud les ambiguités.
> >  > D'aillerus le code INSEE à 5 chiffres des communes n'est qu'une
> >  > simplification, un instantané valable à une année donnée et si on
> >  > n'indique pas le millésime, il n'indique pas de commune précise
> >  > (contrairement au code SIRET de la commune, qui change à chaque
> >  > réaménagement légal, avec des limites toutefois en cas 

Re: [OSM-talk-fr] Osmose : Erreur sur remplacement clés "ref" sur réseaux de transports en commun

[Georges Dutreix via Talk-fr]

J'approuve complètement. 

Les clés network et operator me semblent couvrir pas mal de choses. 

Le 2019-12-13 17:04, deuzeffe a écrit :

> Le 13/12/2019 à 11:46, Quentin Salles a écrit : 
> 
>> Bonjour,
> 
>> - La deuxième, c'est de pouvoir faire simplement une requête overpass afin 
>> de repérer les arrêts du réseau Tisséo.
> 
> Si c'est un réseau, c'est network= Si c'est l'opérateur, c'est operator=
> (à mettre sur la/les relations)
> 
> Cf https://nlehuby.5apps.com/bien-cartographier-les-bus.html___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] HS2 camden updates

[SK53]

On Thu, 12 Dec 2019 at 14:12, Andy Allan  wrote:

> On Thu, 12 Dec 2019 at 14:21, Andy Robinson  wrote:
> >
> > For those keeping an eye on the HS2 Phase 1 preparatory works changes to
> the
> > landscape here is the link to the latest Camden district 12 month look
> ahead
> > which covers Euston and its approaches.
> >
> > http://tiny.cc/r9skhz
>
> For the trivia fans, the document mentions demolishing "Wolfson
> House". This was the location of one of the main OSMF datacentres from
> 2014 to 2016.
>
> Thanks,
> Andy
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb


... and for even more dedicated trivia fans, the building where I did the
bulk of my PhD. In those days the basement held a lecture theatre, a series
of cold rooms and some other equipment, such as a scintillation counter.
Such a shame, it's one of the few buildings I successfully modelled using
S3DB. It was pretty rubbish as a lab though.

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

[talk-cz] Promítnutí změn v OSM nebo chyba editace?

[Radek Papež]

Zdravím,

před třemi týdny jsem provedl úpravu vedení turistické trasy v polském
příhraničí, červená trasa ve skutečnosti totiž vede přímo přes vrchol
Grodczyn
sada změn zde: https://www.openstreetmap.org/changeset/77389905

Zajímalo by mne, zda jsem v něčem neudělal chybu, neboť na OSM.cz ve vrstvě
„Cyklo+Turistická (EU)“ červená trasa stále vede okolo vrcholu, jakoby
žádná úprava neproběhla:
https://openstreetmap.cz/#map=16/50.4139/16.3321=m

Podobně je to na Mapy.cz, které v zahraničí přebírají mapy z OSM, taktéž
beze změny:
https://mapy.cz/s/derupuhute

Je potřeba ještě něco udělat, nebo stačí jen vyčkat (a jak dlouho) na
aktualizaci mapových dlaždic?

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

Re: [OSM-legal-talk] use OSM data to select proprietary data

[Christoph Hormann]

On Friday 13 December 2019, Frederik Ramm wrote:
>
> I had until now assumed that such works would definitely fall under
> the ODbL but you are right, they don't really fit the "Derivative
> Database" definition.

My reading of the ODbL has always been that something is either

1) the original Database (or substantial parts of it)
2) a Derivative Database
3) a Collective Database
4) a Produced Work

or if something is neither of these it would be either

5) something that is not protected by law at all so free to use
independent of the license terms (like insubstantial extracts of data).
6) something the ODbL does not grant any rights for and therefore cannot
be legally used by the user based on the ODbL.

So my question would always be if someone considers certain things not
to be a Derivative Database which of the five other above cases applies
instead.

I would kind of assume that for case (5) there are probably already some
court rulings available for to what extent EU database protection
applies to set operations of different databases since this is nothing
specific to spatial databases but also is relevant for many other types
of data.

As i already wrote in

https://lists.openstreetmap.org/pipermail/talk/2019-November/083535.html

existing OSMF community guidelines suggest spatial operations like
ST_Difference() and ST_Intersection() yield Derivative Databases that
are subject to share-alike.

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

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

Re: [OSM-legal-talk] use OSM data to select proprietary data

[Nuno Caldeira]

well 
https://wiki.osmfoundation.org/wiki/Licence/Licence_and_Legal_FAQ#The_OpenStreetMap_Geodata_Licence


Secondly, you *"Share Alike"*. If you do not make any changes to 
OpenStreetMap data, then you are unlikely to have a "Share Alike" 
obligation. But, if you _publicly distribute something that you have 
made_ from our data, such as a _map or another database_, AND you have 
_added to or enhanced our data_, then we want you to make those 
additions publicly available. We obviously prefer it if you added the 
data straight back to our database, but you do not have to, _as long 
as the public can easily get a copy of what you have done._ If you do 
not publicly distribute anything, then you do not have to share anything. 


Às 19:34 de 13/12/2019, Kathleen Lu via legal-talk escreveu:
Nuno - I think you are operating under the mistaken assumption that a 
CC-BY-SA license would mean that uses such as Mattias's would require 
sharealike.


Here's CC-BY-SA's definition of a Derivative Work:
*"Derivative Work"*means a work based upon the Work or upon the Work 
and other pre-existing works, such as a translation, musical 
arrangement, dramatization, fictionalization, motion picture version, 
sound recording, art reproduction, abridgment, condensation, or any 
other form in which the Work may be recast, transformed, or adapted, 
except that a work that constitutes a Collective Work will not be 
considered a Derivative Work for the purpose of this License. For the 
avoidance of doubt, where the Work is a musical composition or sound 
recording, the synchronization of the Work in timed-relation with a 
moving image ("synching") will be considered a Derivative Work for the 
purpose of this License.


Here's CC-BY-SA's definition of a Collective Work:
*"Collective Work"*means a work, such as a periodical issue, anthology 
or encyclopedia, in which the Work in its entirety in unmodified form, 
along with a number of other contributions, constituting separate and 
independent works in themselves, are assembled into a collective 
whole. A work that constitutes a Collective Work will not be 
considered a Derivative Work (as defined below) for the purposes of 
this License.


As you can see from these examples (which focus on creative 
derivatives, since facts are not even copyrightable in the US and 
there is no US database protection law), a "derivative work" needs 
quite a bit of the original to qualify. The meaning of a "derivative 
work" was always much narrower than what a colloquial understanding of 
what "derived" might be, and the change in license did not change that.


-Kathleen



On Fri, Dec 13, 2019 at 11:11 AM Nuno Caldeira 
mailto:nunocapelocalde...@gmail.com>> 
wrote:


these new Liberal interpretation of ODbL are funny. to bad it's
not documented what we wanted when we changed license. seems to be
full of lies


https://wiki.osmfoundation.org/wiki/Licence/Historic/We_Are_Changing_The_License

/
/
/"This means that “good guys” are stopped from using our data but
the “bad guys” may be able to use it anyway." /
/
/
/" We believe that a reasonable consensus has been built that our
current progress should be to maintain a Share-Alike license (see
more below) but have it written explicitly for data."/
/
/
/"Both licenses are “By Attribution” and “Share Alike”." /
/
/
/"But what happens if the Foundation is taken over by people with
commercial interests?/

  * /You still own the rights to any data you contribute, not the
Foundation. In the new Contributor Terms, you license the
Foundation to publish the data for others to use and ONLY
under a free and open license./

  * /The Foundation is not allowed to take your contribution and
release it under a commercial license./

  * /If the Foundation fails to publish under only a free and open
license, it has broken its contract with you. A copy of the
existing data can be made and released by a different body./

  * /If a change is made to another free and open license, it is
active contributors who decide yes or no, not the Foundation."/



On Fri, 13 Dec 2019, 18:56 Frederik Ramm, mailto:frede...@remote.org>> wrote:

Hi,

On 13.12.19 19:28, Kathleen Lu via legal-talk wrote:
> “Derivative Database” – Means a database based upon the
Database, and
> includes any translation, adaptation, arrangement,
modification, or any
> other alteration of the Database or of a Substantial part of the
> Contents.

Interesting. I knew the ODbL text but I have always glossed
over this
definition, assuming that "well you know what derived means".

I'll have to ponder this for a while, it changes some
assumptions I had
made. It would mean that, for example, a database that
contains a count
of all pubs in 

Re: [OSM-legal-talk] use OSM data to select proprietary data

[Martin Koppenhoefer]

sent from a phone

> On 13. Dec 2019, at 19:56, Frederik Ramm  wrote:
> 
> I'll have to ponder this for a while, it changes some assumptions I had
> made. It would mean that, for example, a database that contains a count
> of all pubs in each municipality,



-> adaptation 


> or a database that contains the
> average travel time from a building in a city to the nearest hospital,


-> adaptation 


> or a heatmap of ice cream parlours,


-> adaptation 



> (and neither could they possibly be used to reassemble
> OSM).


is there a requirement in the ODbL that your adaptation or alteration has to be 
reversible?

Cheers Martin 


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

Re: [OSM-legal-talk] use OSM data to select proprietary data

[Kathleen Lu via legal-talk]

Nuno - I think you are operating under the mistaken assumption that a
CC-BY-SA license would mean that uses such as Mattias's would require
sharealike.

Here's CC-BY-SA's definition of a Derivative Work:
*"Derivative Work"* means a work based upon the Work or upon the Work and
other pre-existing works, such as a translation, musical arrangement,
dramatization, fictionalization, motion picture version, sound recording,
art reproduction, abridgment, condensation, or any other form in which the
Work may be recast, transformed, or adapted, except that a work that
constitutes a Collective Work will not be considered a Derivative Work for
the purpose of this License. For the avoidance of doubt, where the Work is
a musical composition or sound recording, the synchronization of the Work
in timed-relation with a moving image ("synching") will be considered a
Derivative Work for the purpose of this License.

Here's CC-BY-SA's definition of a Collective Work:
*"Collective Work"* means a work, such as a periodical issue, anthology or
encyclopedia, in which the Work in its entirety in unmodified form, along
with a number of other contributions, constituting separate and independent
works in themselves, are assembled into a collective whole. A work that
constitutes a Collective Work will not be considered a Derivative Work (as
defined below) for the purposes of this License.

As you can see from these examples (which focus on creative derivatives,
since facts are not even copyrightable in the US and there is no US
database protection law), a "derivative work" needs quite a bit of the
original to qualify. The meaning of a "derivative work" was always much
narrower than what a colloquial understanding of what "derived" might be,
and the change in license did not change that.

-Kathleen



On Fri, Dec 13, 2019 at 11:11 AM Nuno Caldeira 
wrote:

> these new Liberal interpretation of ODbL are funny. to bad it's not
> documented what we wanted when we changed license. seems to be full of lies
>
>
> https://wiki.osmfoundation.org/wiki/Licence/Historic/We_Are_Changing_The_License
>
> *"This means that “good guys” are stopped from using our data but the “bad
> guys” may be able to use it anyway." *
>
> *" We believe that a reasonable consensus has been built that our current
> progress should be to maintain a Share-Alike license (see more below) but
> have it written explicitly for data."*
>
> *"Both licenses are “By Attribution” and “Share Alike”." *
>
> *"But what happens if the Foundation is taken over by people with
> commercial interests?*
>
>- *You still own the rights to any data you contribute, not the
>Foundation. In the new Contributor Terms, you license the Foundation to
>publish the data for others to use and ONLY under a free and open license.*
>
>
>- *The Foundation is not allowed to take your contribution and release
>it under a commercial license.*
>
>
>- *If the Foundation fails to publish under only a free and open
>license, it has broken its contract with you. A copy of the existing data
>can be made and released by a different body.*
>
>
>- *If a change is made to another free and open license, it is active
>contributors who decide yes or no, not the Foundation."*
>
>
>
> On Fri, 13 Dec 2019, 18:56 Frederik Ramm,  wrote:
>
>> Hi,
>>
>> On 13.12.19 19:28, Kathleen Lu via legal-talk wrote:
>> > “Derivative Database” – Means a database based upon the Database, and
>> > includes any translation, adaptation, arrangement, modification, or any
>> > other alteration of the Database or of a Substantial part of the
>> > Contents.
>>
>> Interesting. I knew the ODbL text but I have always glossed over this
>> definition, assuming that "well you know what derived means".
>>
>> I'll have to ponder this for a while, it changes some assumptions I had
>> made. It would mean that, for example, a database that contains a count
>> of all pubs in each municipality, or a database that contains the
>> average travel time from a building in a city to the nearest hospital,
>> or a heatmap of ice cream parlours, would not fall under the ODbL
>> because these, while derived from OSM, do not actually contain a copy of
>> anything in OSM (and neither could they possibly be used to reassemble
>> OSM).
>>
>> I had until now assumed that such works would definitely fall under the
>> ODbL but you are right, they don't really fit the "Derivative Database"
>> definition.
>>
>> Bye
>> Frederik
>>
>> --
>> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>>
>> ___
>> legal-talk mailing list
>> legal-talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/legal-talk
>>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
___
legal-talk mailing list
legal-talk@openstreetmap.org

Re: [OSM-legal-talk] use OSM data to select proprietary data

[Nuno Caldeira]

these new Liberal interpretation of ODbL are funny. to bad it's not
documented what we wanted when we changed license. seems to be full of lies

https://wiki.osmfoundation.org/wiki/Licence/Historic/We_Are_Changing_The_License

*"This means that “good guys” are stopped from using our data but the “bad
guys” may be able to use it anyway." *

*" We believe that a reasonable consensus has been built that our current
progress should be to maintain a Share-Alike license (see more below) but
have it written explicitly for data."*

*"Both licenses are “By Attribution” and “Share Alike”." *

*"But what happens if the Foundation is taken over by people with
commercial interests?*

   - *You still own the rights to any data you contribute, not the
   Foundation. In the new Contributor Terms, you license the Foundation to
   publish the data for others to use and ONLY under a free and open license.*


   - *The Foundation is not allowed to take your contribution and release
   it under a commercial license.*


   - *If the Foundation fails to publish under only a free and open
   license, it has broken its contract with you. A copy of the existing data
   can be made and released by a different body.*


   - *If a change is made to another free and open license, it is active
   contributors who decide yes or no, not the Foundation."*



On Fri, 13 Dec 2019, 18:56 Frederik Ramm,  wrote:

> Hi,
>
> On 13.12.19 19:28, Kathleen Lu via legal-talk wrote:
> > “Derivative Database” – Means a database based upon the Database, and
> > includes any translation, adaptation, arrangement, modification, or any
> > other alteration of the Database or of a Substantial part of the
> > Contents.
>
> Interesting. I knew the ODbL text but I have always glossed over this
> definition, assuming that "well you know what derived means".
>
> I'll have to ponder this for a while, it changes some assumptions I had
> made. It would mean that, for example, a database that contains a count
> of all pubs in each municipality, or a database that contains the
> average travel time from a building in a city to the nearest hospital,
> or a heatmap of ice cream parlours, would not fall under the ODbL
> because these, while derived from OSM, do not actually contain a copy of
> anything in OSM (and neither could they possibly be used to reassemble
> OSM).
>
> I had until now assumed that such works would definitely fall under the
> ODbL but you are right, they don't really fit the "Derivative Database"
> definition.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] use OSM data to select proprietary data

[Martin Koppenhoefer]

sent from a phone

> On 13. Dec 2019, at 19:32, matthias.straetl...@buerotiger.de wrote:
> 
> So as soon I'm selecting any data using OSM polygons, it gets transformed OSM 
> data?
> They're not even touching on the same layer, since it's a different feature 
> type.


if you modify your data based on OpenStreetMap data you are creating a 
derivative database.

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

Re: [OSM-legal-talk] use OSM data to select proprietary data

[Frederik Ramm]

Hi,

On 13.12.19 19:28, Kathleen Lu via legal-talk wrote:
> “Derivative Database” – Means a database based upon the Database, and
> includes any translation, adaptation, arrangement, modification, or any
> other alteration of the Database or of a Substantial part of the
> Contents.

Interesting. I knew the ODbL text but I have always glossed over this
definition, assuming that "well you know what derived means".

I'll have to ponder this for a while, it changes some assumptions I had
made. It would mean that, for example, a database that contains a count
of all pubs in each municipality, or a database that contains the
average travel time from a building in a city to the nearest hospital,
or a heatmap of ice cream parlours, would not fall under the ODbL
because these, while derived from OSM, do not actually contain a copy of
anything in OSM (and neither could they possibly be used to reassemble
OSM).

I had until now assumed that such works would definitely fall under the
ODbL but you are right, they don't really fit the "Derivative Database"
definition.

Bye
Frederik

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

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

Re: [OSM-legal-talk] use OSM data to select proprietary data

[matthias . straetling]

Hi Mateusz,

>> No, ODbL does not apply to any database that does not include OSM data.
> It is true but misleading to mention here as this database contains 
> transformed OSM data.
 
So if I don't merge the postcodes, it's fine?

>> There is no OSM data in the secondary list so it is not a Derivative 
>> Database.
> This is blatantly untrue. There is OSM data there, only transformed.

So as soon I'm selecting any data using OSM polygons, it gets transformed OSM 
data?
They're not even touching on the same layer, since it's a different feature 
type.

Regards,
Matthias


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

Re: [OSM-legal-talk] use OSM data to select proprietary data

[Kathleen Lu via legal-talk]

Hi Frederik,

Here's why I disagree. The meaning of "derived" in a colloquial sense and
the definition of "Derivative Database" are not the same.
While colloquially, it may be fair to interpret "derived" as "made from" or
"could not have been made without", that is not the legal definition of
"Derivative Database".

>From ODbL:
“Derivative Database” – Means a database based upon the Database, and
includes any translation, adaptation, arrangement, modification, or any
other alteration of the Database or of a Substantial part of the
Contents. This includes, but is not limited to, Extracting or
Re-utilising the whole or a Substantial part of the Contents in a new
Database.

So a Derivative Database must include a "translation, adaptation,
arrangement, modification, or any other alteration of the Database or of a
Substantial part of the
Contents." In other words, it has to include in the new database at least a
substantial part of what was in the previous database.
The inference of "with pubs" would not be, in my mind, a "translation,
adaptation, arrangement, modification, or any other alteration of the
Database or of a Substantial part of the
Contents" because it is too minor of an inference.
I view Mattias's usecase as *using* OSM, not *making a Derivative Database
from OSM*.
I would also say that, looking back at the EU Database Directive, I do not
see a case for breach of the restricted rights, particularly the right of
"translation, adaptation, arrangement and any other alteration."

With respect to Mateusz's more extreme example, this is also very
specifically covered in the Geocoding Guidelines: "A collection of
Geocoding Results will be considered a systematic attempt to aggregate data
if it is used as a general purpose geodatabase, regardless of how the
original aggregation was accomplished."

In other worse, if, as in Mateusz's hypothetical, you attempt to abuse the
system to reverse engineer a database that is equivalent to OSM, you make a
Derivative Database. But Mattias has been very clear that is not what he's
doing. He just wants to display the subparts of a list of points he already
has on a different layer than the other subparts.

-Kathleen


On Fri, Dec 13, 2019 at 12:49 AM Frederik Ramm  wrote:

> Kathleen,
>
> On 12.12.19 23:40, Kathleen Lu via legal-talk wrote:
> > No, ODbL does not apply to any database that does not include OSM data.
>
> Are you sure about this? Let me give an example:
>
> > If I understand your usecase correctly, Matthais, you are essentially
> > checking your list against OSM boundaries. If something is both on your
> > list and within the OSM boundary, then you say 'yes, this goes on the
> > secondary list.' Then you want to publish your secondary list. There is
> > no OSM data in the secondary list so it is not a Derivative Database.
>
> Let us assume I have a list of all streets in Germany with their
> geometry, from a non-OSM source.
>
> I want to divide these into two groups: streets that have at least one
> pub, and streets that have no pub.
>
> Using OSM information about the location of pubs, I count the number of
> pubs along each street, allowing me to make the desired separation.
>
> I end up with a database of "streets that have at least one pub". This
> database does not include OSM data.
>
> In my eyes, though, it is still *derived* from OSM data. It is the
> result of an algorithmic process that has made use of OSM data; if you
> will, the OSM data residue is in the name/description of my new
> database: "roads with pubs". It is derived from OSM; it could not have
> been made without OSM.
>
> Do you disagree?
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] use OSM data to select proprietary data

[matthias . straetling]

Hi Lars-Daniel, yeah, same here.

 

I've read you tried to do similar work in the past. I think, you've merged postcodes with OSM data in a seperate column and didn't need to attribute it as share-alike.



 

What did you end up with?

 


Gesendet: Freitag, 13. Dezember 2019 um 19:25 Uhr
Von: "Lars-Daniel Weber" 
An: legal-talk@openstreetmap.org
Betreff: Re: [OSM-legal-talk] use OSM data to select proprietary data



Please stop constructing such cases. This case clearly would have the intention of reproducing the OSM database.

My intention is the trivial use of OpenStreetMap. A normal process in the GIS world.






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

Re: [OSM-legal-talk] use OSM data to select proprietary data

[Lars-Daniel Weber]

Please stop constructing such cases. This case clearly would have the intention of reproducing the OSM database.

My intention is the trivial use of OpenStreetMap. A normal process in the GIS world.

 




Gesendet: Freitag, 13. Dezember 2019 um 10:44 Uhr
Von: "Mateusz Konieczny" 
An: "Licensing and other legal discussions." 
Betreff: Re: [OSM-legal-talk] use OSM data to select proprietary data


 

 

 

13 Dec 2019, 09:48 by frede...@remote.org:


I end up with a database of "streets that have at least one pub". This

database does not include OSM data.

 

In my eyes, though, it is still *derived* from OSM data. It is the

result of an algorithmic process that has made use of OSM data; if you

will, the OSM data residue is in the name/description of my new

database: "roads with pubs". It is derived from OSM; it could not have

been made without OSM.


Or more extreme.

 

(1) I create database of points on the grid of 0.1 cm.

(2) I create two list, first contains what according to OSM is on land,

second contains what according to OSM data is water

(3) I claim that both lists are not ODBL licenced.

 

Are you going to claim that also this one is legally sound, and not Mapbox-tier

"attribution hidden behind mystery meat "(i)" navigation

fulfills ODBL attribution requirement" swindle?
___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk




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

Re: [Talk-it] negozio elettroforniture

[Andrea Musuruane]

Constato che la wiki piace poco e si legge sempre meno:
https://wiki.openstreetmap.org/wiki/Tag:shop%3Delectrical

Ciao,

Andrea


On Fri, Dec 13, 2019 at 6:59 PM demon_box  wrote:

> ciao come taggereste voi un negozio di elettroforniture che vende sia al
> dettaglio che all'ingrosso?
>
> shop=electrician_supply  ???
>
> --enrico
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] negozio elettroforniture

[demon_box]

ciao come taggereste voi un negozio di elettroforniture che vende sia al
dettaglio che all'ingrosso?

shop=electrician_supply  ???

--enrico




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

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

Re: [OSM-talk-fr] Osmose : Erreur sur remplacement clés "ref" sur réseaux de transports en commun

[Quentin Salles]

Bonsoir,

@deauzeffe Ce que tu dis est juste dans le cas où je cherche les arrêts de
bus pour une ligne donnée.
Or dans ce que je disais, ça concernait l'ensemble des arrêts desservis par
toutes les lignes du réseau Tisséo

Quentin SALLES

Le ven. 13 déc. 2019 à 17:55, laurent-38  a
écrit :

> Frédéric Rodrigo-2 wrote
> > Le principe des règles, c'est de corrigé les données, pas les règles.
> > La règle est valide et basé sur le wiki OSM.
> >
> > Le 10/12/2019 à 14:48, Quentin Salles a écrit :
> >> …
> >> Aujourd'hui, Osmose
> >> signale tous les arrêts de bus ayant un mauvais suffixe d'attribut sur
> >> la clé "ref:FR:Tisséo".
>
> Bonjour Frédéric,
>
> Peux-tu préciser le sens de ta réponse ?
>
> S’agit-il de supprimer les accents dans les clés tels que ref:FR:Tisséo (ou
> ref:Transisère) ? Le wiki ne me semble pas l’interdire :
> https://wiki.openstreetmap.org/wiki/Any_tags_you_like#Characters
>
> Ou bien s’agit-il d’enregistrer ces clés dans une « liste blanche », type
>
> https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales
> ,
> pour qu’elles soient considérées comme correctes ?
>
> Cordialement
> ~~
> laurent
>
>
>
> --
> 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-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose : Erreur sur remplacement clés "ref" sur réseaux de transports en commun

[laurent-38]

Frédéric Rodrigo-2 wrote
> Le principe des règles, c'est de corrigé les données, pas les règles.
> La règle est valide et basé sur le wiki OSM.
> 
> Le 10/12/2019 à 14:48, Quentin Salles a écrit :
>> …
>> Aujourd'hui, Osmose 
>> signale tous les arrêts de bus ayant un mauvais suffixe d'attribut sur 
>> la clé "ref:FR:Tisséo".

Bonjour Frédéric,

Peux-tu préciser le sens de ta réponse ?

S’agit-il de supprimer les accents dans les clés tels que ref:FR:Tisséo (ou
ref:Transisère) ? Le wiki ne me semble pas l’interdire :
https://wiki.openstreetmap.org/wiki/Any_tags_you_like#Characters

Ou bien s’agit-il d’enregistrer ces clés dans une « liste blanche », type
https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales,
pour qu’elles soient considérées comme correctes ?

Cordialement
~~
laurent



--
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-gb-westmidlands] HS2 phase 1 updates - Solihull interchange station

[Andy Robinson]

The link below provides info on compounds and new highway bridge structures
being set-up and constructed next year in and around the proposed
interchange station by the NEC.

https://tinyurl.com/rmspe8q

Cheers
Andy


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

Re: [OSM-talk-fr] ref:FR:FANTOIR

[deuzeffe]

Je te parle des codes communes pour lesquels tu n'as donné aucune 
référence fiable et validée. Ne détourne pas la conversation steuplé.


Le 13/12/2019 à 05:30, Philippe Verdy a écrit :

Ne me fais pas croire que le FANTOIR est décrit dans le COG, même en 2019.
Là c'est toi qui confond, ce n'est même pas la même source (et il n'y a 
pas de synchro directe entre les deux, toujours des décalages)!


COG: source INSEE (https://www.insee.fr/fr/information/2016807)
FANTOIR: source DGFIP 
(https://www.data.gouv.fr/fr/datasets/fichier-fantoir-des-voies-et-lieux-dits/)


Je sais faire la différence merci.

Le FANTOIR utilise des codes communes complets à 6 chiffres (3 pour le 
département métropole+direction ou pour les DOM; puis 3 pour la commune 
même dans les DOM, mais pas synchronisé immédiatement et partour avec le 
COG du même millésime), après le code RIVOLI du type de voie (1 lettre), 
et avant le numéro de voie sur 4 chiffres (unique par code RIVOLI plus 
code commune à 6 chiffres); le dernier caractère est une lettre-clé 
calculée sur les 11 caractères précédents (code RIVOLI du type de voie, 
département+direction+commune, numéro de voie)


Bref les codes commune complets du COG et ceux du FANTOIR sont 
différents en forme et en usage même si à l'origine le FANTOIR a basé 
ses codes commune sur le code INSEE des commune issu du COG. Le COG n'a 
aucun "code direction" et réduit les codes communes de 3 à 2 chiffres 
dans les DOM en ajoutant un chiffre au département.


On peut se passer de la lettre clé finale (après la lettre RIVOLI et les 
6+4 chiffres) dans la base (elle n'ajoute aucune précision, c'est juste 
une vérification).


Si on réduit le code commune complet de 6 chiffres à 5 chiffres, la 
lettre clé finale n'est plus correcte, mais quoi qu'il en soit elle 
n'est toujours pas identifiante mais permet de déduire le chiffre 
manquant dans le code commune complet à 6 chiffres).


Des corrections semi-automatiques sont possibles selon la forme trouvée:
- 4 chiffres plus 1 lettre : il manque la commune (requête géographique 
semi-automatique); la lettre clé finale est présente, on peut en déduire 
le code RIVOLI initial du type de voie grace à la lettre-clé finale 
après avoir déduit la commune, mais problème dans les départements ayant 
plusieurs directions, car alors on aura plusieurs codes RIVOLI de type 
de voie déduits et on ne peut pas choisir (correction donc manuelle, le 
code direction n'est pas forcément 0 à Paris, dans le Nord, dans le 
Rhône ou les Bouches-du-Rhône, mais les directions sont des secteurs 
géographiques dans un département, on s'en sort donc).
- 4 chiffres: on ne peut rien faire, il manque la lettre code RIVOLI 
initiale pour le rendre unique, cas d'erreur.
- 1 lettre plus 4 chiffres : il manque les 6 chiffres du code 
département+direction+commune FANTOIR, puis la lettre-clé calculable. On 
peut cherche la commune par requête géographique (à confirmer, attention 
aux pièges des communes fusionnées, il peut y avoir encore plusieurs 
codes possibles car pas de synchro immédiate du FANTOIR avec le COG).
- 1 lettre plus 10 chiffres : il manque juste la lettre clé finale 
calculable automatiquement.



Le jeu. 12 déc. 2019 à 22:56, deuzeffe > a écrit :


Ne me fais pas croire que tu ne sais pas trouver les pages qui
décrivent
très précisément le COG et tous les champs. C'est sûr que c'est moins
facile de trouver le dernier COG du printemps-été 2019 avec toutes la
liste de toutes les communes et leur identifiant unique que de peigner
la girafe, mais quand même.

Bref.

Le 12/12/2019 à 22:49, Philippe Verdy a écrit :
 > Le COG ne répond pas à ça concernant le FANTOIR, et les codes
communes
 > ne sont pas si uniques que ça (il y a tout un historique lié aux
 > fusions/défusions, et réaménagement de frontières communales ou
 > réaffectations de voies limitrophes) ! Le définition des tues est
une
 > compétence communale, mais comme les communes changent aussi, ce
n'est
 > pas en passant à l'échelle départementale avec le COG actuel qu'on
 > résoud les ambiguités.
 > D'aillerus le code INSEE à 5 chiffres des communes n'est qu'une
 > simplification, un instantané valable à une année donnée et si on
 > n'indique pas le millésime, il n'indique pas de commune précise
 > (contrairement au code SIRET de la commune, qui change à chaque
 > réaménagement légal, avec des limites toutefois en cas d'échanges
 > parcellaires d'une commune à l'autre sans changer les entités
légales).
 > Ensuite pour la fiscalité locale applicable et le cadastre ça
devient
 > vite compliqu (y compris avec des communes qui ont changé de
département
 > à l'occasion d'une fusion en commune nouvelle, les communes
déléguées
 > conservant encore le code de leur ancien département dont elle ne
font
 > plus partie!)
 > Le FANTOIR (ou RIVOLI très 

Re: [OSM-talk-fr] Osmose : Erreur sur remplacement clés "ref" sur réseaux de transports en commun

[deuzeffe]

Le 13/12/2019 à 11:46, Quentin Salles a écrit :

Bonjour,


- La deuxième, c'est de pouvoir faire simplement une requête overpass 
afin de repérer les arrêts du réseau Tisséo.


Si c'est un réseau, c'est network= Si c'est l'opérateur, c'est operator=
(à mettre sur la/les relations)

Cf https://nlehuby.5apps.com/bien-cartographier-les-bus.html

--
deuzeffe - pourquoi faire simple quand on peut faire compliqué. Et si je 
dis des bêtises, je compte sur Noëmie pour me corriger


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

Re: [Talk-it] Errore per link dinamico di Overpass turbo per umap

[Volker Schmidt]

Non è questo il problema. La query originale non li aveva e aveva  già
fatto il problema descritto. Ho introdotto i regex in un tentativo di
ridurre il numero di caratteri.
Come ho detto prima ho superato il problema lato Overpass. Adesso mi sono
inceppato in uno lato uMap:
Mi sembra che sia un limite complessivo sul numero di oggetti (dinamici?)
che un uMap può gestire. Avevo caricato tre layers con successo. Poi
caricato un quarto,  un pò più pesante. Non veniva visualizzato. Rimosso
uno dei primi tre e mi appare il quarto.




On Fri, 13 Dec 2019, 13:57 Martin Koppenhoefer, 
wrote:

> non so se c’entra con il tuo problema (probabilmente no), ma quella query
> mi sembra abbastanza “cara” in quanto sono tutte regex invece di confronti
> semplici. Potresti semplificare molto mettendo direttamente i filtri
> specifici come highway=cycleway piuttosto che highway=tutto che comincia
> con cy,
> etc.
>
> Ciao Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [talk-cz] Historie OSM v CZ

[Tom Ka]

Ten aktualni prohlizec delal ZbyCZ a urcite neni dokonaly, ja ale
nemam kapacitu si s tim ted nejak dal hrat, to neni na chvilku. Proto
jsem v prvnim mailu psal, ze uvitam nekoho na pomoc s UI.

Kazdopadne bych rekl, ze tohle co popisujes je spis snaha prohlizece
uchovat to v cache, jestli se s tim da nebo neda neco delat ale
netusim.

Bye

pá 13. 12. 2019 v 13:38 odesílatel Jan Macura  napsal:
>
> Ahoj,
>
> Tome, je to skvělý.
> Jen mám pocit, že čím dál jdu do historie, tím pomaleji se dlaždice načítají, 
> někdy i v opačném pořadí, když skáču vpřed/vzad/vpřed/.., resp. s velkým 
> zpožděním. Nenačítají se ty jednotlivé dlaždice přes sebe? I objem dat v RAM 
> by tomu napovídal, že prohlížeč se snaží zobrazit všechny najednou...
>
> Díky
>  H.
>
> On Fri, 13 Dec 2019 at 09:10, Tom Ka  wrote:
>>
>> Ahoj,
>>
>> Hotovo.
>>
>> - nejstarsi pouzitelny OSM soubor je z 2006.04.03. U techto hodne
>> starych je dost uzlu i nejake cesty, ale minimum ma nejake tagy. Videt
>> jsou tak napr. mosty pri max. priblizeni (jen jmeno):  Karluv most a
>> okoli - https://osm.fit.vutbr.cz/cz_old/2006-04-03/15/17695/11100.png
>> - prokazatelne nejstarsi dohledatelny uzel v CZ je podle vseho z
>> 2005-08-15: https://www.openstreetmap.org/node/172533/history
>>   (podle cisla uzlu je nejstarsi zreme
>> https://www.openstreetmap.org/node/172508 kousek vedle, ale k tomu jiz
>> starsi historicka data nejsou)
>> - OSM bohuzel nema k dispozici starsi historii, proste to tenkrat
>> nikdo neschoval, coz je trochu skoda. Jsou k dispozici zmenove soubory
>> po dni od 2005.04.17 ale neni k nim pocatecni OSM, takze jejich
>> pouziti je velmi omezene (napr. se podle nich dat urcit ten uzel
>> 172533).
>>
>> Tak se nam z ukolu do hry pro OpenAlt vyklubala docela zajimava "zabava" :-)
>>
>> Bye tom.k
>>
>> po 9. 12. 2019 v 8:39 odesílatel Tom Ka  napsal:
>> >
>> > Ahoj,
>> >
>> > na adrese https://kasparkovi.net/osm/ najdete dalsi varku starych
>> > verzi OSM mapy, aktualne az do 2007.05 a jeste jich par pribude!
>> >
>> > (Dotaz na Slovensko, mel by nekdo zajem o to same pro SK - at jiz
>> > extra nebo rozsireni stavajici mapy?)
>> >
>> > (A dotaz na Zbyho pripadne na ostatni - dobrovolnik na vylepseni
>> > rozhrani pro prohlizeni starych vrstev?)
>> >
>> > Bye tom.k
>>
>> ___
>> talk-cz mailing list
>> talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz

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

Re: [OSM-talk-fr] ref:FR:FANTOIR

[Xavier BIZOT]

Bonjour,

Le peu d'erreurs sur la Bretagne ont été corrigé de mon côté :)

Xavier

Le ven. 13 déc. 2019 à 11:09,  a écrit :

> https://overpass-turbo.eu/s/OWF
>
> Là tu ne devrais avoir que des incorrects.
>
> Visiblement des Nantais ont lu ton message !
>
> Jean-Yvon
> Le 13/12/2019 à 02:07, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
>
> Il y a plusieurs ref:FR:FANTOIR avec un code direction différent de 0 en
> région parisienne, il y en a aussi à Dunkerque et autour avec le code
> direction 1 . On les enlève ?
>
> J'ai corrigé pas mal de ref:FR:FANTOIR, sur toute la France, beaucoup de
> code direction 0 et aussi des fautes de frappe. Mais il y en reste encore.
> Si ça tente des gens de continuer les corrections, on trouve les codes de
> 11 caractères comme ça : https://overpass-turbo.eu/s/OWl
>
> Pour tous les code qui pose problème car pas 10 caractères :
> https://overpass-turbo.eu/s/OWn (il y a aussi les cas de bon code séparé
> par un ; qui ne sont pas des erreurs)
> Le gros des erreurs (les 3/4 environ) se trouvent dans l'agglomération
> nantaise, se ne sont pas les code fantoir dans ref:FR:FANTOIR mais le code
> rivoli donc il fait entre 1 et 4 caractères (les 0 du début sont absent),
> on pourrait ajouter le code insee de la commune avant le code déjà présent
> mais on aurait que les 9 1er caractères et il manquerait le dernier :(
> Il y a aussi un gros groupe de ref:FR:FANTOIR trop long sur des adresses
> car il y a après le code : "-le numéro" donc pour faire ça comme il faut il
> faudrait avec ces numéros créer les relations associateStreet pour y placer
> le fantoir.
> Après ces 2 gros groupes, il y a d'autres erreurs un peu partout sur toute
> la france...
>
> Avis aux amateurs, si certains veulent faire des corrections...
> Sinon on supprime ces codes faux...
>
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Errore per link dinamico di Overpass turbo per umap

[Martin Koppenhoefer]

non so se c’entra con il tuo problema (probabilmente no), ma quella query mi 
sembra abbastanza “cara” in quanto sono tutte regex invece di confronti 
semplici. Potresti semplificare molto mettendo direttamente i filtri specifici 
come highway=cycleway piuttosto che highway=tutto che comincia con cy,
etc.

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

Re: [OSM-talk-fr] ref:FR:FANTOIR

[Donat ROBAUX]

Avant de voir ce message, j'ai déposé une petite issue sur Github:
https://github.com/osm-fr/osm-vs-fantoir/issues/71

A commenter, amender si le sujet vous parle.



--
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-cz] [osm_sk] Re: Historie OSM v CZ

[Jan Macura]

On Fri, 13 Dec 2019 at 09:19, Tom Ka  wrote:

> pá 13. 12. 2019 v 9:16 odesílatel Peter Misovic
>  napsal:
> >
> > Ahoj, mne to nefunguje mimo Ciech. Cache som vymazal.
> > Mam urobit este nieco?
>
> je to jen pro CZ, viz SUBJ a dotaz, jestli nekdo stoji i o SK (je to
> docela dost prace)
>
>
Tazatele možná zmátlo, že při prvním načtení dat se zobrazí ČR+SR+Rakousko.
Historická data pak už jen pro ČR ;-)

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

Re: [talk-cz] Historie OSM v CZ

[Jan Macura]

Ahoj,

Tome, je to skvělý.
Jen mám pocit, že čím dál jdu do historie, tím pomaleji se dlaždice
načítají, někdy i v opačném pořadí, když skáču vpřed/vzad/vpřed/.., resp. s
velkým zpožděním. Nenačítají se ty jednotlivé dlaždice přes sebe? I objem
dat v RAM by tomu napovídal, že prohlížeč se snaží zobrazit všechny
najednou...

Díky
 H.

On Fri, 13 Dec 2019 at 09:10, Tom Ka  wrote:

> Ahoj,
>
> Hotovo.
>
> - nejstarsi pouzitelny OSM soubor je z 2006.04.03. U techto hodne
> starych je dost uzlu i nejake cesty, ale minimum ma nejake tagy. Videt
> jsou tak napr. mosty pri max. priblizeni (jen jmeno):  Karluv most a
> okoli - https://osm.fit.vutbr.cz/cz_old/2006-04-03/15/17695/11100.png
> - prokazatelne nejstarsi dohledatelny uzel v CZ je podle vseho z
> 2005-08-15: https://www.openstreetmap.org/node/172533/history
>   (podle cisla uzlu je nejstarsi zreme
> https://www.openstreetmap.org/node/172508 kousek vedle, ale k tomu jiz
> starsi historicka data nejsou)
> - OSM bohuzel nema k dispozici starsi historii, proste to tenkrat
> nikdo neschoval, coz je trochu skoda. Jsou k dispozici zmenove soubory
> po dni od 2005.04.17 ale neni k nim pocatecni OSM, takze jejich
> pouziti je velmi omezene (napr. se podle nich dat urcit ten uzel
> 172533).
>
> Tak se nam z ukolu do hry pro OpenAlt vyklubala docela zajimava "zabava"
> :-)
>
> Bye tom.k
>
> po 9. 12. 2019 v 8:39 odesílatel Tom Ka  napsal:
> >
> > Ahoj,
> >
> > na adrese https://kasparkovi.net/osm/ najdete dalsi varku starych
> > verzi OSM mapy, aktualne az do 2007.05 a jeste jich par pribude!
> >
> > (Dotaz na Slovensko, mel by nekdo zajem o to same pro SK - at jiz
> > extra nebo rozsireni stavajici mapy?)
> >
> > (A dotaz na Zbyho pripadne na ostatni - dobrovolnik na vylepseni
> > rozhrani pro prohlizeni starych vrstev?)
> >
> > Bye tom.k
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-fr] gestion du hstore dans qgis

[Jérôme Seigneuret]

Oui c'est un truc qui t'évite de gérer le délimiteur de valeur et remplace
donc par $$ donc pas d'échappement à gérer. exemple de clé ou la valeur
contenant un simple cote ou un double cote utilisé comme paramètre de ta
requête

y compris les `` ou "

Je parlais ce ça car le mieux c'est d'uniformiser et surtout de pas avec
des caratères différent pour délimiter un champs




Le ven. 13 déc. 2019 à 12:18, Leroy Olivier  a écrit :

> Un pro de postgre te fera sûrement une réponse plus fine que moi.   Ici
> c'est une forme de quoting qui te permet "d’éviter" les autres formes de
> quoting (comme ') et \ et ne pas à avoir à les "echapper". Dans ma tête
> c'est un "super quote".
>
> Le ven. 13 déc. 2019 à 12:02, Tony Emery via Talk-fr <
> talk-fr@openstreetmap.org> a écrit :
>
>> Merci Olivier pour ta contribution.
>> Rappelle-moi ce que signifie les $$ ?
>>
>>
>>
>> -
>> Tony EMERY
>> OpenStreetMap.fr
>> Ingénieur SIG
>> --
>> 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
>>
>
>
> --
> Olivier Leroy
> Docteur Géographie et Environnement
> Post-doctorant EVS ANR Rêveries 
> 06.18.37.18.08
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [Talk-lt] addr:flat

[Tomas Straupis]

Hello

2019-12-13, pn, 13:16 Rihards rašė:
> In the Baltic states, addr:flat is used only on two nodes in Lithuania:
> https://www.openstreetmap.org/node/4146739382
> https://www.openstreetmap.org/node/4240999727
> Notice how it's singular, as opposed to addr:flats.
> addr:flats is used ~17 times in the world, addr:flat - 141 times
> (and is not documented).
> Could it be that these two instances were supposed to be addr:flats (or
> perhaps addr:unit)?

  On both nodes addr:flat identifies a number of a flat in a block
house where small business is situated.

  add:flats (as per wiki) describes "which addresses are behind the
door". So as I understand, in the same block house you would have one
or more entrances and on those entrances you would add something like
add:flats=1-50. So addr:flats is a different thing from what is being
described in two nodes you presented.

  add:unit is a different concept, it is a separate building in the
set of buildings with the same address. For example in Vismaliukai (in
Vilnius) we have a number of buildings with the same address but
different unit numbers.
  https://www.openstreetmap.org/#map=18/54.75254/25.41544
  So again, addr:unit is not the thing which is being described in the
two presented nodes.

  Therefore I would say tagging is fine. Being present/described or
not in OSM wiki is a different question :-)

-- 
Tomas

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

Re: [OSM-talk-fr] gestion du hstore dans qgis

[Leroy Olivier]

Un pro de postgre te fera sûrement une réponse plus fine que moi.   Ici
c'est une forme de quoting qui te permet "d’éviter" les autres formes de
quoting (comme ') et \ et ne pas à avoir à les "echapper". Dans ma tête
c'est un "super quote".

Le ven. 13 déc. 2019 à 12:02, Tony Emery via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Merci Olivier pour ta contribution.
> Rappelle-moi ce que signifie les $$ ?
>
>
>
> -
> Tony EMERY
> OpenStreetMap.fr
> Ingénieur SIG
> --
> 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
>


-- 
Olivier Leroy
Docteur Géographie et Environnement
Post-doctorant EVS ANR Rêveries 
06.18.37.18.08
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-lt] addr:flat

[Rihards]

Hi, dear Lithuanian community.

In the Baltic states, addr:flat is used only on two nodes in Lithuania:

https://www.openstreetmap.org/node/4146739382
https://www.openstreetmap.org/node/4240999727

Notice how it's singular, as opposed to addr:flats.

addr:flats is used ~17 times in the world, addr:flat - 141 times
(and is not documented).

Could it be that these two instances were supposed to be addr:flats (or
perhaps addr:unit)?
-- 
 Rihards

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

Re: [OSM-talk-fr] Osmose : Erreur sur remplacement clés "ref" sur réseaux de transports en commun

[lenny.libre]

Le 13/12/2019 à 11:13, marc marc a écrit :

Bonjour,

Je me demande le sens de cet ultra spécialisation de la clef ref qu'on 
ne trouve pas dans d'autres clés.
Avoir une clef ref avec un namespace devrait être utile quand il y a 
plusieurs ref (arrêt multi opérateur)

C'est justement le cas https://www.openstreetmap.org/node/776080030

mais quand il y a qu'une, cette habitude est un non sens.
C'est un peu comme on remplaçait les name par name:FR:lacommune pour 
préciser que la commune à donné le name puis opening_hours:lecommerce 
pour dire que ce sont les heures selon le commerce et ainsi de suite.
Je pense qu'on a perdu de vue là non duplication des données au profit 
d'une utilisation fainéante des données.
PS je ne vise pas ce cas en particulier, je parle d'une manière 
générale de la sur utilisation parfois inutile des espaces de nom.


Cordialement,
Marc



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

Re: [OSM-talk-fr] gestion du hstore dans qgis

[Tony Emery via Talk-fr]

Merci Olivier pour ta contribution.
Rappelle-moi ce que signifie les $$ ?



-
Tony EMERY
OpenStreetMap.fr
Ingénieur SIG
--
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: [OSM-talk-fr] Osmose : Erreur sur remplacement clés "ref" sur réseaux de transports en commun

[Frédéric Rodrigo]

Le 13/12/2019 à 11:55, Yves P. a écrit :

@Xavier

/*Pour certaines informations, il est vivement conseillé de se rendre 
sur le terrain ou d'utiliser StreetView (ou équivalent Mapillary). */


Pour ces attributs il est uniquement conseillé de le faire de visu... 
Et la promotion de StreetView n'est pas obligatoire…


Il faudrait trouver une appellation neutre et en français pour parler 
de Mapillary, OpenStreetCam et Google Street View : "vue terrestre » ?



Le problème c'est surtout qu'il ne PAS utiliser Google StreetView.



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

Re: [OSM-talk-fr] Osmose : Erreur sur remplacement clés "ref" sur réseaux de transports en commun

[Yves P.]

@Xavier

> Pour certaines informations, il est vivement conseillé de se rendre sur le 
> terrain ou d'utiliser StreetView (ou équivalent Mapillary).  
> 
> Pour ces attributs il est uniquement conseillé de le faire de visu... Et la 
> promotion de StreetView n'est pas obligatoire…

Il faudrait trouver une appellation neutre et en français pour parler de 
Mapillary, OpenStreetCam et Google Street View : "vue terrestre » ?

Quand à aller sur le terrain c’est l’idéal, mais pas toujours possible quand on 
fait des corrections à distance ou qu’on est cloué dans un lit ou un fauteuil, 
qu’on n’a pas de moyen de transport, et j’en oublie probablement…

Il n’y a pas toujours de de photos Mapillary, OpenStreetCam, Wikimedia Commons…
Je suis bien content de trouver des vues à 360° chez Google.

Je m’en sert pour contrôler que l’objet à bien existant à l’instant t (date de 
la prise de vue), ou qu’il y a eu des modifications sur le terrain.

J’ai cartographié de poteaux incendie avec GSV, et quand j’ai pu aller sur le 
terrain (si, si, ça m’arrive ), celui-ci avait traversé la rue.
D’où l’intérêt de bien regarder la date de prise de vue (quelque soit la 
source) et de mettre un fixme=A vérifier sur le terrain…

@Marc
> Je me demande le sens de cet ultra spécialisation de la clef ref qu'on ne 
> trouve pas dans d'autres clés.
> Avoir une clef ref avec un namespace devrait être utile quand il y a 
> plusieurs ref (arrêt multi opérateur) mais quand il y a qu'une, cette 
> habitude est un non sens.
> […]
> Je pense qu'on a perdu de vue là non duplication des données au profit d'une 
> utilisation fainéante des données.
Le problème est de pouvoir lier des données entre OSM et des bases de données 
externe de manière fiable.

Et de pouvoir le faire pour un même objet avec plusieurs bases.

En attendant de gérer ça sous wikidata (et on est loin d’y arriver), je ne vois 
pas comment faire autrement.

Exemple des feux et des phares :
ref:nga
ref:admiralty
ref:xxx pour des livres de feux nationaux.
Quand la référence à un préfixe ou une « forme » caractéristique (clé Mapillary 
par exemple), un humain peut deviner, un logiciel aussi mais il faut pouvoir 
rajouter le code (cf. PR sur OSM)
Et encore, à condition d’être un « spécialiste » du domaine.
Mais pour les références nationales (et bien d’autres références dans d’autres 
domaines), c’est juste un numéro.

Comment vérifier la référence, où trouver les données liées ?

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

Re: [OSM-talk-fr] Osmose : Erreur sur remplacement clés "ref" sur réseaux de transports en commun

[Quentin Salles]

Bonjour,

@Marc marc
Après, j'ai proposé la surcharge de cette clé pour 2 raisons :
- La première c'est que plusieurs réseaux majeurs de transports en commun
utilise cette clé (RATP, STAR, etc)
- La deuxième, c'est de pouvoir faire simplement une requête overpass afin
de repérer les arrêts du réseau Tisséo.

@Xavier Bizot et Jérome
Je partage votre avis sur cette phrase. Cette dernière existait déjà avant
que je change profondément la page. Il est vrai que c'est un non-sens de
promouvoir un outil non libre, je vais le modifier dans la foulée.

Bonne journée

Quentin SALLES

Le ven. 13 déc. 2019 à 11:00, Quentin Salles  a
écrit :

> Bonjour,
>
> Je vous informe avoir modifié la page
> https://wiki.openstreetmap.org/wiki/Toulouse/Transports_en_commun
> afin de prendre en compte le "ref:FR:Tisséo".
>
> Cordialement
>
> Quentin SALLES
>
> Le mer. 11 déc. 2019 à 18:55, lenny.libre  a
> écrit :
>
>> En ce qui concerne le réseau Arc-en-Ciel, quand nous avons choisi le nom
>> de l'attribut je l'ai ajouté avec son explication dans le wiki, pour ma
>> part, je n'ai rien fait d'autre ; quelqu'un a dû le lire pour mettre la
>> règle dans osmose car je ne reçois pas le message que nous recevons pour
>> Tisséo.
>>
>> Je te conseille de le modifier et de le signaler quand la modif sera
>> faite, en réponse à ton message
>>
>> Leni
>> Le 10/12/2019 à 15:02, Quentin Salles a écrit :
>>
>> Bonjour Frédéric,
>>
>> Si dans le Wiki OSM de "Toulouse/Transports en commun", je mets à jour la
>> règle, alors ce sera pris en charge par Osmose ?
>> Quelle est la procédure pour prendre en compte ce changement ?
>>
>>
>>
>> Le mar. 10 déc. 2019 à 14:53, Frédéric Rodrigo 
>> a écrit :
>>
>>> Le principe des règles, c'est de corrigé les données, pas les règles.
>>> La règle est valide et basé sur le wiki OSM.
>>>
>>>
>>>
>>> Le 10/12/2019 à 14:48, Quentin Salles a écrit :
>>> > Bonjour,
>>> >
>>> > Après avoir demandé à la mail-list de Toulouse, j'ai récemment
>>> > entrepris de mettre à jour et de remplacer la clé "ref" par
>>> > "ref:FR:Tisséo" sur les arrêts de bus toulousains. Aujourd'hui, Osmose
>>> > signale tous les arrêts de bus ayant un mauvais suffixe d'attribut sur
>>> > la clé "ref:FR:Tisséo". Est-il possible de corriger cette règle dans
>>> > le code d'Osmose ?
>>> >
>>> > Cordialement.
>>> >
>>> > Quentin SALLES
>>> >
>>> > ___
>>> > Talk-fr mailing list
>>> > Talk-fr@openstreetmap.org
>>> > https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>>
>> ___
>> Talk-fr mailing 
>> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] gestion du hstore dans qgis

[Leroy Olivier]

Bonjour,

Pour les arbres j'ai une requête sql (postgresql) un peu monstre qui génère
une autre requête avec tous les champs dans le hstore (y compris les `` ou
""). Tu peux modifier cette seconde requête avant de la lancer.

SELECT format($$ SELECT osm_id, tags->%s
> FROM planet_osm_point
> WHERE planet_osm_point.natural = 'tree' ; $$
> , string_agg(quote_literal(key) || ' AS ' || quote_ident(key), $$,
> tags->$$))
> AS arbre_tag_sql
> FROM (
> SELECT DISTINCT key
> FROM planet_osm_point, skeys(tags) key
> WHERE planet_osm_point.natural = 'tree'
> ORDER BY 1
> ) sub;
>

Il faut bien sûr changer planet_osm_point et planet_osm_point.natural =
"tree" pour ta table d’intérêt et ton objet d’intérêt.  J'ai ensuite fait
une jointure par l'osm_id et explorer/regarder les valeurs d’intérêt. Dans
les arbres cela ne fait "que" 199 champs pour un peu moins d'un million de
lignes donc cela passe pas trop mal.

Voici ma maigre contribution et merci pour cette question et échanges que
je trouve assez intéressante !

Olivier

Le ven. 13 déc. 2019 à 11:00, Tony Emery via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> pyrog wrote
> > Imbriquer les guillemets simple dans des doubles (ou vice versa), ça ne
> > fonctionne pas ?
>
> J'ai tout essayé, même la danse du ventre...
>
>
>
>
> -
> Tony EMERY
> OpenStreetMap.fr
> Ingénieur SIG
> --
> 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
>


-- 
Olivier Leroy
Docteur Géographie et Environnement
Post-doctorant EVS ANR Rêveries 
06.18.37.18.08
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose : Erreur sur remplacement clés "ref" sur réseaux de transports en commun

[Jérôme Seigneuret]

De plus Streetview n'est pas autorisé pour cela! As supprimer dans les plus
bref délai

A+

Le ven. 13 déc. 2019 à 11:28, Xavier BIZOT  a
écrit :

> J'ai lu la page avec attention...
>
> Par contre je m'interroge sur cette phrase personnellement :
> *Pour certaines informations, il est vivement conseillé de se rendre sur
> le terrain ou d'utiliser StreetView (ou équivalent Mapillary). *
>
> Pour ces attributs il est uniquement conseillé de le faire de visu... Et
> la promotion de StreetView n'est pas obligatoire...
>
> C'est un avis personnel évidemment.
>
>
>
> Le ven. 13 déc. 2019 à 11:01, Quentin Salles 
> a écrit :
>
>> Bonjour,
>>
>> Je vous informe avoir modifié la page
>> https://wiki.openstreetmap.org/wiki/Toulouse/Transports_en_commun
>> afin de prendre en compte le "ref:FR:Tisséo".
>>
>> Cordialement
>>
>> Quentin SALLES
>>
>> Le mer. 11 déc. 2019 à 18:55, lenny.libre  a
>> écrit :
>>
>>> En ce qui concerne le réseau Arc-en-Ciel, quand nous avons choisi le nom
>>> de l'attribut je l'ai ajouté avec son explication dans le wiki, pour ma
>>> part, je n'ai rien fait d'autre ; quelqu'un a dû le lire pour mettre la
>>> règle dans osmose car je ne reçois pas le message que nous recevons pour
>>> Tisséo.
>>>
>>> Je te conseille de le modifier et de le signaler quand la modif sera
>>> faite, en réponse à ton message
>>>
>>> Leni
>>> Le 10/12/2019 à 15:02, Quentin Salles a écrit :
>>>
>>> Bonjour Frédéric,
>>>
>>> Si dans le Wiki OSM de "Toulouse/Transports en commun", je mets à jour
>>> la règle, alors ce sera pris en charge par Osmose ?
>>> Quelle est la procédure pour prendre en compte ce changement ?
>>>
>>>
>>>
>>> Le mar. 10 déc. 2019 à 14:53, Frédéric Rodrigo 
>>> a écrit :
>>>
 Le principe des règles, c'est de corrigé les données, pas les règles.
 La règle est valide et basé sur le wiki OSM.



 Le 10/12/2019 à 14:48, Quentin Salles a écrit :
 > Bonjour,
 >
 > Après avoir demandé à la mail-list de Toulouse, j'ai récemment
 > entrepris de mettre à jour et de remplacer la clé "ref" par
 > "ref:FR:Tisséo" sur les arrêts de bus toulousains. Aujourd'hui,
 Osmose
 > signale tous les arrêts de bus ayant un mauvais suffixe d'attribut
 sur
 > la clé "ref:FR:Tisséo". Est-il possible de corriger cette règle dans
 > le code d'Osmose ?
 >
 > Cordialement.
 >
 > Quentin SALLES
 >
 > ___
 > Talk-fr mailing list
 > Talk-fr@openstreetmap.org
 > https://lists.openstreetmap.org/listinfo/talk-fr



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


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

Re: [OSM-talk-fr] gestion du hstore dans qgis

[Yves P.]

> J'ai tout essayé, même la danse du ventre…
Tu peux mettre une vidéo en ligne stp 

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

Re: [OSM-talk-fr] gestion du hstore dans qgis

[Jérôme Seigneuret]

@Tony quelle version de Postgresql Postgis as tu? Tu as fait quelle
configuration ? Encodage de base etc.

('amenity_pnt', 'amenity IS NOT NULL’, ’amenity', ‘name', *‘*access’, 'tags
-> *"*ref:FR:FANTOIR*"*', 'dispatch_point’),

Il y a un problème ici  tu as des guillemets en mode MySQL dans la chaîne
qui ne correspondent pas à ce qu'attend Postgresql

Après -> c'est pas un Cast  hstore -> text c'est une recherche de valeur
donc plutôt  => '"tags" => *"*ref:FR:FANTOIR*"*'  ?

Après une la recherche IS NULL tu peux surement faire une recherche avec
exist(...)





Le ven. 13 déc. 2019 à 11:00, Tony Emery via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> pyrog wrote
> > Imbriquer les guillemets simple dans des doubles (ou vice versa), ça ne
> > fonctionne pas ?
>
> J'ai tout essayé, même la danse du ventre...
>
>
>
>
> -
> Tony EMERY
> OpenStreetMap.fr
> Ingénieur SIG
> --
> 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
>


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

Re: [OSM-talk-fr] Osmose : Erreur sur remplacement clés "ref" sur réseaux de transports en commun

[Xavier BIZOT]

J'ai lu la page avec attention...

Par contre je m'interroge sur cette phrase personnellement :
*Pour certaines informations, il est vivement conseillé de se rendre sur le
terrain ou d'utiliser StreetView (ou équivalent Mapillary). *

Pour ces attributs il est uniquement conseillé de le faire de visu... Et la
promotion de StreetView n'est pas obligatoire...

C'est un avis personnel évidemment.



Le ven. 13 déc. 2019 à 11:01, Quentin Salles  a
écrit :

> Bonjour,
>
> Je vous informe avoir modifié la page
> https://wiki.openstreetmap.org/wiki/Toulouse/Transports_en_commun
> afin de prendre en compte le "ref:FR:Tisséo".
>
> Cordialement
>
> Quentin SALLES
>
> Le mer. 11 déc. 2019 à 18:55, lenny.libre  a
> écrit :
>
>> En ce qui concerne le réseau Arc-en-Ciel, quand nous avons choisi le nom
>> de l'attribut je l'ai ajouté avec son explication dans le wiki, pour ma
>> part, je n'ai rien fait d'autre ; quelqu'un a dû le lire pour mettre la
>> règle dans osmose car je ne reçois pas le message que nous recevons pour
>> Tisséo.
>>
>> Je te conseille de le modifier et de le signaler quand la modif sera
>> faite, en réponse à ton message
>>
>> Leni
>> Le 10/12/2019 à 15:02, Quentin Salles a écrit :
>>
>> Bonjour Frédéric,
>>
>> Si dans le Wiki OSM de "Toulouse/Transports en commun", je mets à jour la
>> règle, alors ce sera pris en charge par Osmose ?
>> Quelle est la procédure pour prendre en compte ce changement ?
>>
>>
>>
>> Le mar. 10 déc. 2019 à 14:53, Frédéric Rodrigo 
>> a écrit :
>>
>>> Le principe des règles, c'est de corrigé les données, pas les règles.
>>> La règle est valide et basé sur le wiki OSM.
>>>
>>>
>>>
>>> Le 10/12/2019 à 14:48, Quentin Salles a écrit :
>>> > Bonjour,
>>> >
>>> > Après avoir demandé à la mail-list de Toulouse, j'ai récemment
>>> > entrepris de mettre à jour et de remplacer la clé "ref" par
>>> > "ref:FR:Tisséo" sur les arrêts de bus toulousains. Aujourd'hui, Osmose
>>> > signale tous les arrêts de bus ayant un mauvais suffixe d'attribut sur
>>> > la clé "ref:FR:Tisséo". Est-il possible de corriger cette règle dans
>>> > le code d'Osmose ?
>>> >
>>> > Cordialement.
>>> >
>>> > Quentin SALLES
>>> >
>>> > ___
>>> > Talk-fr mailing list
>>> > Talk-fr@openstreetmap.org
>>> > https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>>
>> ___
>> Talk-fr mailing 
>> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>>
>> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose : Erreur sur remplacement clés "ref" sur réseaux de transports en commun

[marc marc]

Bonjour,

Je me demande le sens de cet ultra spécialisation de la clef ref qu'on ne 
trouve pas dans d'autres clés.
Avoir une clef ref avec un namespace devrait être utile quand il y a plusieurs 
ref (arrêt multi opérateur) mais quand il y a qu'une, cette habitude est un non 
sens.
C'est un peu comme on remplaçait les name par name:FR:lacommune pour préciser 
que la commune à donné le name puis opening_hours:lecommerce pour dire que ce 
sont les heures selon le commerce et ainsi de suite.
Je pense qu'on a perdu de vue là non duplication des données au profit d'une 
utilisation fainéante des données.
PS je ne vise pas ce cas en particulier, je parle d'une manière générale de la 
sur utilisation parfois inutile des espaces de nom.

Cordialement,
Marc

Le 13 déc. 2019 à 11:00, Quentin Salles 
mailto:quentin.salle...@gmail.com>> a écrit :

Bonjour,

Je vous informe avoir modifié la page 
https://wiki.openstreetmap.org/wiki/Toulouse/Transports_en_commun
afin de prendre en compte le "ref:FR:Tisséo".

Cordialement

Quentin SALLES

Le mer. 11 déc. 2019 à 18:55, lenny.libre 
mailto:lenny.li...@orange.fr>> a écrit :

En ce qui concerne le réseau Arc-en-Ciel, quand nous avons choisi le nom de 
l'attribut je l'ai ajouté avec son explication dans le wiki, pour ma part, je 
n'ai rien fait d'autre ; quelqu'un a dû le lire pour mettre la règle dans 
osmose car je ne reçois pas le message que nous recevons pour Tisséo.

Je te conseille de le modifier et de le signaler quand la modif sera faite, en 
réponse à ton message

Leni

Le 10/12/2019 à 15:02, Quentin Salles a écrit :
Bonjour Frédéric,

Si dans le Wiki OSM de "Toulouse/Transports en commun", je mets à jour la 
règle, alors ce sera pris en charge par Osmose ?
Quelle est la procédure pour prendre en compte ce changement ?



Le mar. 10 déc. 2019 à 14:53, Frédéric Rodrigo 
mailto:fred.rodr...@gmail.com>> a écrit :
Le principe des règles, c'est de corrigé les données, pas les règles.
La règle est valide et basé sur le wiki OSM.



Le 10/12/2019 à 14:48, Quentin Salles a écrit :
> Bonjour,
>
> Après avoir demandé à la mail-list de Toulouse, j'ai récemment
> entrepris de mettre à jour et de remplacer la clé "ref" par
> "ref:FR:Tisséo" sur les arrêts de bus toulousains. Aujourd'hui, Osmose
> signale tous les arrêts de bus ayant un mauvais suffixe d'attribut sur
> la clé "ref:FR:Tisséo". Est-il possible de corriger cette règle dans
> le code d'Osmose ?
>
> Cordialement.
>
> Quentin SALLES
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr





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


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

Re: [OSM-talk-fr] ref:FR:FANTOIR

[osm . sanspourriel]

https://overpass-turbo.eu/s/OWF

Là tu ne devrais avoir que des incorrects.

Visiblement des Nantais ont lu ton message !

Jean-Yvon

Le 13/12/2019 à 02:07, Jérôme Amagat - jerome.ama...@gmail.com a écrit :

Il y a plusieurs ref:FR:FANTOIR avec un code direction différent de 0
en région parisienne, il y en a aussi à Dunkerque et autour avec le
code direction 1 . On les enlève ?

J'ai corrigé pas mal de ref:FR:FANTOIR, sur toute la France, beaucoup
de code direction 0 et aussi des fautes de frappe. Mais il y en reste
encore. Si ça tente des gens de continuer les corrections, on trouve
les codes de 11 caractères comme ça : https://overpass-turbo.eu/s/OWl

Pour tous les code qui pose problème car pas 10 caractères :
https://overpass-turbo.eu/s/OWn (il y a aussi les cas de bon code
séparé par un ; qui ne sont pas des erreurs)
Le gros des erreurs (les 3/4 environ) se trouvent dans l'agglomération
nantaise, se ne sont pas les code fantoir dans ref:FR:FANTOIR mais le
code rivoli donc il fait entre 1 et 4 caractères (les 0 du début sont
absent), on pourrait ajouter le code insee de la commune avant le code
déjà présent mais on aurait que les 9 1er caractères et il manquerait
le dernier :(
Il y a aussi un gros groupe de ref:FR:FANTOIR trop long sur des
adresses car il y a après le code : "-le numéro" donc pour faire ça
comme il faut il faudrait avec ces numéros créer les relations
associateStreet pour y placer le fantoir.
Après ces 2 gros groupes, il y a d'autres erreurs un peu partout sur
toute la france...

Avis aux amateurs, si certains veulent faire des corrections...
Sinon on supprime ces codes faux...




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

Re: [OSM-talk-fr] Osmose : Erreur sur remplacement clés "ref" sur réseaux de transports en commun

[Quentin Salles]

Bonjour,

Je vous informe avoir modifié la page
https://wiki.openstreetmap.org/wiki/Toulouse/Transports_en_commun
afin de prendre en compte le "ref:FR:Tisséo".

Cordialement

Quentin SALLES

Le mer. 11 déc. 2019 à 18:55, lenny.libre  a écrit :

> En ce qui concerne le réseau Arc-en-Ciel, quand nous avons choisi le nom
> de l'attribut je l'ai ajouté avec son explication dans le wiki, pour ma
> part, je n'ai rien fait d'autre ; quelqu'un a dû le lire pour mettre la
> règle dans osmose car je ne reçois pas le message que nous recevons pour
> Tisséo.
>
> Je te conseille de le modifier et de le signaler quand la modif sera
> faite, en réponse à ton message
>
> Leni
> Le 10/12/2019 à 15:02, Quentin Salles a écrit :
>
> Bonjour Frédéric,
>
> Si dans le Wiki OSM de "Toulouse/Transports en commun", je mets à jour la
> règle, alors ce sera pris en charge par Osmose ?
> Quelle est la procédure pour prendre en compte ce changement ?
>
>
>
> Le mar. 10 déc. 2019 à 14:53, Frédéric Rodrigo  a
> écrit :
>
>> Le principe des règles, c'est de corrigé les données, pas les règles.
>> La règle est valide et basé sur le wiki OSM.
>>
>>
>>
>> Le 10/12/2019 à 14:48, Quentin Salles a écrit :
>> > Bonjour,
>> >
>> > Après avoir demandé à la mail-list de Toulouse, j'ai récemment
>> > entrepris de mettre à jour et de remplacer la clé "ref" par
>> > "ref:FR:Tisséo" sur les arrêts de bus toulousains. Aujourd'hui, Osmose
>> > signale tous les arrêts de bus ayant un mauvais suffixe d'attribut sur
>> > la clé "ref:FR:Tisséo". Est-il possible de corriger cette règle dans
>> > le code d'Osmose ?
>> >
>> > Cordialement.
>> >
>> > Quentin SALLES
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] gestion du hstore dans qgis

[Tony Emery via Talk-fr]

pyrog wrote
> Imbriquer les guillemets simple dans des doubles (ou vice versa), ça ne
> fonctionne pas ?

J'ai tout essayé, même la danse du ventre...




-
Tony EMERY
OpenStreetMap.fr
Ingénieur SIG
--
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-it] Errore per link dinamico di Overpass turbo per umap

[Volker Schmidt]

Grazie della rapida reazione.
Risolto.
Ecco i dettagli
Il problema è tutto sul lato Overpass, prima d qualsiasi operazione su lato
uMap.

> Effettivamente non sembra lunga.

Non sembra lunga la query nel formato WIzard, ma la conversione in Overpass
GL lo è in fatti (55 righe)

> Accertati:
>
> - aver impostato nella query il formato "xml"
>
dove?


> - aver impostato nella "remote data" di umap il link della compact
> query e non la stringa
> - che in umap il formato sia "osm"
>
Questo riguardebbe il lato uMap e  funziona tutto come altre query che
sono, in Overpass GL, meno "verbosi"

> Per facilitare le prova anche ad altri, manda il link della query
> invece di uno spezzone di testo.
>
Non è un spezzone di testo che ho mandato, è la query in formato Overpass
turbo Wizard.
Per riprodurre il problema, devi
1) incollare questo  "testo" nel Wizard:
"

type:way

and

(highway=cycleway or ((highway=track or highway=path) and

(bicycle=designated or bicycle=official)))

and

(foot=no or foot!=*)

and

((oneway!=* and oneway:bicycle!=*) or (oneway=no and oneway:bicycle=no))

and

cycleway!=crossing

and

track!=crossing

and

path!=crossing

in Padova
"
2) "build query" nella finestrina del Wizard
Questo produce una query in Overpass GL di 55 righe
3) manualmente aumentare il timeout (da 25 a 100 secondi) nella quarta riga
di questa query Overpass GL.
4) lanciare "run"
(Si vede il risultato, dopo un po' di attesa  - sono 58 oggetti a Padova
3) lanciare l'export:
"Export" > "Query" > "convert to compact"

E' questo tentativo di esportare i dati da Overpass che fallisce.con il
messaggio di errore del server di Overpass::
"
Request-URI Too Long

The requested URL's length exceeds the capacity limit for this server.
--
Apache/2.4.18 (Ubuntu) Server at lz4.overpass-api.de Port 80
"

Altre query più brevi funzionano senza problemi con questio metodo che
viene proposto da questi autori:
http://www.mappa-mercia.org/2014/09/creating-an-always-up-to-date-map.html
Questo funziona per query "leggeri".
Nel caso della mia query "pesante" non funziona.
Una scelta alternativa nel menu del export funziona:
"Export" > "Query" > "download/copy as umap remote data url"

In un altro text editor, incolla la stringa scaricata o copiata e
inserisci *davanti
*la seguente stringa:
http://overpass-api.de/api/interpreter?data=
Questo URI funziona poi in uMap com link dinamico:

   1. seleziona "Remote Data"
   2. incolla URI nelcamp "Url"
   3. seleziona OSM copme formato dasti
   4. ativa "dynamic"
   5. salva

Volker







> Il giorno gio 12 dic 2019 alle ore 22:57 Volker Schmidt
>  ha scritto:
> >
> > Sto modificando una umap con link stastici a link dinamici e mi sono
> impatuto che link lunghi non si esportano da Overpass turbo.
> > Ho una query created con Overpass turbo wizard:
> >
> > type:way
> > and
> > (highway~"^cy" or ((highway~"^tr" or highway=path) and
> > (bicycle~"^de" or bicycle~"^of")))
> > and
> > (foot=no or foot!=*)
> > and
> > ((oneway!=* and oneway:bicycle!=*) or (oneway=no and oneway:bicycle=no))
> > and
> > cycleway!~"^cr"
> > and
> > track!~"^cr"
> > and
> > path!~"^cr"
> > in Padova
> >
> > La faccio girare semza problema e mi seleziona correttamante 58 ogeti.
> > Per creare un link dinamico
> > clicco in sequenza: "Export", "Query", "convert to compact"
> > Funziona bene per query non troppo complesse, ma per l'esempio mi viene
> fuori "Request-URI Too Long"
> >
> > Qualche consiglio o devo fare una mappa statica?
> >
> > Volker
> >
> >
> >
> >
> >
> > ___
> > Talk-it mailing list
> > Talk-it@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-it
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] gestion du hstore dans qgis

[Tony Emery via Talk-fr]

Denis, je retire ce que j'ai dit : ton astuce fonctionne, je l'ai testé sur
une autre clé...
Je vais donc faire ma tambouille dans ce coin là.



-
Tony EMERY
OpenStreetMap.fr
Ingénieur SIG
--
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: [OSM-talk-fr] gestion du hstore dans qgis

[Yves P.]

@Tony
> ('amenity_pnt', 'amenity IS NOT NULL','amenity, name, access,tags -> 
> 'ref:FR:FANTOIR'', 'dispatch_point’),

> Du coup, les guillements de la clé hstore entrent en conflit avec les 
> guillements de ma table. J'ai essayé de doubler les guillements, de les 
> supprimer, rien y fait.
Imbriquer les guillemets simple dans des doubles (ou vice versa), ça ne 
fonctionne pas ?

('amenity_pnt', 'amenity IS NOT NULL’, ’amenity', ‘name', ‘access’, 'tags -> 
"ref:FR:FANTOIR"', 'dispatch_point’),

—
Yves

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

Re: [talk-cz] [osm_sk] Re: Historie OSM v CZ

[Vaclav Kroupar]

Mrknul jsem se na okoli Chomutova, hodil nejstarsi mapu a rikal si: Je to 
rozbyty. Nez mi doslo, ze tehdy zde mapa jeste neexistovala. Pak jsem se 
proklikaval dal a koukal, co jsem maloval (moc toho neni). 

Diky
Vasek Kroupar

> 13. 12. 2019 v 9:22, Tom Ka :
> 
> pá 13. 12. 2019 v 9:16 odesílatel Peter Misovic
>  napsal:
>> 
>> Ahoj, mne to nefunguje mimo Ciech. Cache som vymazal.
>> Mam urobit este nieco?
> 
> je to jen pro CZ, viz SUBJ a dotaz, jestli nekdo stoji i o SK (je to
> docela dost prace)
> 
> Bye tom.k
> 
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz


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

Re: [OSM-talk-fr] Appel à l'aide à propos d'une série de premières contributions assez catastrophiques

[FR via Talk-fr]

Le 12/12/2019 à 16:28, marc marc a écrit :



Le 12 déc. 2019 à 16:13, FR via Talk-fr  a écrit :

Est-ce qu’il est possible avec iD de remonter dans l’historique

Il y a un lien en bas à gauche vers osm.org pour afficher l'historique.
Mais iD comme Josm sans plugin reverter ne permet à ma connaissance pas 
d'annuler la supression.


Il ne s'agit pas d'annuler une suppression mais de remonter à l'état 
précédent d'un objet pour récupérer les anciennes valeurs des balises et 
les coordonnées des points. Le menu "Outils > Déplacer un nœud" permet 
de repositionner des points déplacés. C'est du bricolage par 
copier-coller fastidieux mais ça dépanne. Quant aux objets effacés on 
peut toujours retrouver quelques points pour s'en faire une idée à 
partir de  l'orthophoto, après c'est la connaissance du terrain qui 
permet ou pas  de boucher les trous...


FR, qui adore débrouiller les ficelles


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

Re: [OSM-talk-fr] gestion du hstore dans qgis

[Tony Emery via Talk-fr]

Denis, j'ai essayé ta solution mais cela ne revoit rien alors que je sais que
la clé existe.

Etienne, c'est ce que j'ai essayé au départ : dans le script, je créé une
table avec les thématiques à extraire :
CREATE TABLE public.thematique (diminutif varchar(50), condition
varchar(250), attribut varchar (250), fonction varchar (50));
INSERT INTO public.thematique VALUES
('amenity_pnt', 'amenity IS NOT NULL','amenity, name, access',
'dispatch_point'),
...[les autres thématiques]...

et j'ai une fonction 'dispatch_point' qui parcours cette table pour créer
les tables thématiques, notamment la partie :
requete := 'CREATE TABLE public.'||tabname||' AS (SELECT osm_id,
'||filtre_vars||', osm_user, osm_timestamp, tags, id_serial, date_import,
coordx, coordy, lastmodif, num_keys, the_geom FROM public.ccpro_point WHERE
'||filtre_theme||');

Sauf que si je veux extraire les hstores, c'est par exemple tags ->
'ref:FR:FANTOIR' as fantoir, dans la table, ça donnerai :
('amenity_pnt', 'amenity IS NOT NULL','amenity, name, access,tags ->
'ref:FR:FANTOIR'', 'dispatch_point'),
Du coup, les guillements de la clé hstore entrent en conflit avec les
guillements de ma table. J'ai essayé de doubler les guillements, de les
supprimer, rien y fait.





-
Tony EMERY
OpenStreetMap.fr
Ingénieur SIG
--
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: [OSM-legal-talk] use OSM data to select proprietary data

[Mateusz Konieczny]

13 Dec 2019, 09:48 by frede...@remote.org:

> I end up with a database of "streets that have at least one pub". This
> database does not include OSM data.
>
> In my eyes, though, it is still *derived* from OSM data. It is the
> result of an algorithmic process that has made use of OSM data; if you
> will, the OSM data residue is in the name/description of my new
> database: "roads with pubs". It is derived from OSM; it could not have
> been made without OSM.
>
Or more extreme. 

(1) I create database of points on the grid of 0.1 cm.
(2) I create two list, first contains what according to OSM is on land,
second contains what according to OSM data is water
(3) I claim that both lists are not ODBL licenced.

Are you going to claim that also this one is legally sound, and not Mapbox-tier 
"attribution hidden behind mystery meat "(i)" navigation 
fulfills ODBL attribution requirement" swindle?
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] use OSM data to select proprietary data

[Mateusz Konieczny]

12 Dec 2019, 23:40 by legal-talk@openstreetmap.org:
> No, ODbL does not apply to any database that does not include OSM data.

It is true but misleading to mention here as this database contains transformed 
OSM data.

> Can I use OSM data and OpenStreetMap-derived maps to verify my own data 
without triggering share-alike?

Mentioning this here is extremely misleading. 

> If something is both on your list and within the OSM boundary, then you say 
> 'yes, 
this goes on the secondary list.' Then you want to publish your secondary list. 

Note "you should be able to reasonably demonstrate that any such change was made
 either from your own physical observation or comes from a non-OpenStreetMap 
source
 accessed directly by you. I.e you can compare but not take!"

Note "you should visit the street and check the name, then you are free to put 
that 
name in your data as it is your own observation."

You are allowed to use this "secondary list" only and solely to pinpoint data 
that is 
likely to be wrong and requires verification. List itself is OSM derived and 
ODBL apply.
 
> There is no OSM data in the secondary list so it is not a Derivative Database.

This is blatantly untrue. There is OSM data there, only transformed. 

12 Dec 2019, 23:40 by legal-talk@openstreetmap.org:

> No, ODbL does not apply to any database that does not include OSM data. There 
> are two reasons.
>
> First, this example is analogous to the FAQ here: > 
> 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
> Can I use OSM data and OpenStreetMap-derived maps to verify my own data 
> without triggering share-alike?
>
> Yes, provided that you are only comparing and do not copy any OpenStreetMap 
> data. If you make any changes to your data after making the comparison, you 
> should be able to reasonably demonstrate that any such change was made either 
> from your own physical observation or comes from a non-OpenStreetMap source 
> accessed directly by you. I.e you can compare but not take!
>
> Example 1: You notice that a street is called one name on your map and 
> another in OpenStreetMap. You should visit the street and check the name, 
> then you are free to put that name in your data as it is your own observation.
> Example 2: You notice that a boundary is different in your data and 
> OpenStreetMap. You should check back to original authoritative sources and 
> make any correction required.
>
> When someone does example #1 above, they compare OSM data and nonOSM data and 
> make a list of streets to check in the real world. Neither the nonOSM data 
> nor the list of streets needs to be licensed under ODbL. You may *compare* 
> freely. 
> If I understand your usecase correctly, Matthais, you are essentially 
> checking your list against OSM boundaries. If something is both on your list 
> and within the OSM boundary, then you say 'yes, this goes on the secondary 
> list.' Then you want to publish your secondary list. There is no OSM data in 
> the secondary list so it is not a Derivative Database.
>
> Second, see the Geocoding Guidelines, which Martin also pointed out - > 
> https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Geocoding_-_Guideline#The_Guideline>
>   
> Your example is akin to using OSM polygons for certain areas to geocode. You 
> already have the lat/long for your points (houses and flats), so what you are 
> getting from OSM is equivalent to the name of the area you are filtering 
> against (e.g., all these points are in neighborhood X). 
> The Geocoding Guidelines specifically state "if only names are provided in 
> Geocoding Results from OSM -- in particular, latitude/longitude information 
> from OSM is not included in the Geocoding Results -- > a collection of such 
> results is not a substantial extract> ." 
> Thus, no ODbL obligations attach.
>
> -Kathleen
>
>  
>
>
>
>
> On Thu, Dec 12, 2019 at 11:55 AM Nuno Caldeira <> 
> nunocapelocalde...@gmail.com> > wrote:
>
>> does contain derivate however,which means license applies 
>>
>> On Thu, 12 Dec 2019, 19:46 , <>> matthias.straetl...@buerotiger.de>> > wrote:
>>
>>> > we are here to create more open data, not to feed proprietary data than 
>>> > is lock under their TOS.  
>>>  
>>>  I want to apologize for my misunderstanding: my final product does not 
>>> contain any OpenStreetMap data.
>>>  
>>>  ___
>>>  legal-talk mailing list
>>>  >>> legal-talk@openstreetmap.org
>>>  >>> https://lists.openstreetmap.org/listinfo/legal-talk
>>>
>> ___
>>  legal-talk mailing list
>>  >> legal-talk@openstreetmap.org
>>  >> https://lists.openstreetmap.org/listinfo/legal-talk
>>

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

[talk-cz] WeeklyOSM CZ 489

[Tom Ka]

Ahoj, je dostupné vydání 489 týdeníku WeeklyOSM:

https://weeklyosm.eu/cz/archives/12610

* Svatojakubská cesta.
* Polední menu v OSM?
* Kdo není @anonymaps?
* Mapování slumů drony.
* Esperanto pro celý svět?
* Volby do rady Nadace OSM.
* OSM data pro úřady.
* Mapování Indie 1:500.
* Konference Baltic GIS.
* Missing Maps slaví 5let.
* Nové Switch2OSM.
* Vytváření GeoPDF.
* Komu patří Krym?
* Kamera Mapillary.

Pěkné počtení ...

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

Re: [OSM-talk-fr] Appel à l'aide à propos d'une série de premières contributions assez catastrophiques

[Violaine_Do]

Il y a OSMCha aussi, qui détecte les tout nouveaux... : 
https://osmcha.mapbox.com/


Bon courage...

On 30/11/2019 01:27, Eric wrote:

Bonjour,

Je pense qu'on peut progresser dans l'accueil et la vérif des travaux 
pour les nouveau arrivants. Moi, j'ai écrit il y a peu mon premier 
article Wikipédia et dans les 24h je recevais des commentaires de 
plusieurs contributeurs avec des corrections à apporter pour respecter 
les standards ou des conseils pour progresser. C'est bien je trouve. 
Sur OSM, je ne connais que WhoDidIt pour suivre les évolutions sur les 
zones que je connais.
Par exemple, une liste chronologique de tous les changeset pour les 
contributeurs à moins de NN modifs me paraitrait intéressant pour 
réagir vite en cas de bêtise.


Eric

Le sam. 30 nov. 2019 à 11:30, marc marc > a écrit :


Bonjour,

Le 30.11.19 à 10:28, Cédric Frayssinet a écrit :
> Quand on voit certains manuels scolaires de la matière et le
traitement
> des activités OSM dessus

tu as un document dispo en ligne à ce sujet ?

> Marc, as-tu une procédure pour trouver ces nouveaux contributeurs,
> idéalement, il faudrait repérer de nombreux nouveaux comptes
crées et
> qui ont contribué au moins une fois dans un secteur restreint. Si on
> localise un lycée, je peux envisager de contacter le lycée.

moi j'utilise osmbot sur le canal irc #osm-fr-annonce
il annonce tous les nouveaux contributeurs en temps réel avec le lieu.
Pascal Neis a aussi l'info avec une interface web
http://resultmaps.neis-one.org/newestosm?c=France#6/46.784/1.996

une suggestion de message de bienvenue est dispo sur le wiki
https://wiki.openstreetmap.org/wiki/FR:France/bienvenue

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


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


--
Violaine_Do

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

Re: [OSM-talk-fr] adresse mail rejetée

[lenny.libre]

Le 12/12/2019 à 21:59, osm.sanspourr...@spamgourmet.com a écrit :


J'appelle ceci un message d'erreur, même si c'est en étranger^^ :
 Message transféré 

Sujet : Re: [OSM-talk-fr] adresse mail rejetée
Date :  Thu, 12 Dec 2019 20:57:49 +
De :talk-fr-ow...@openstreetmap.org



Your message has been rejected, probably because you are not
subscribed to the mailing list and the list's policy is to prohibit
non-members from posting to it. If you think that your messages are
being rejected in error, contact the mailing list owner at
talk-fr-ow...@openstreetmap.org.



J'ai le même quand je me trompe d'adresse d'expédition, mais c'est normal.

Ce qu'il faudrait pouvoir récupérer c'est le message de rejet (que 
reçoit la liste) pour pouvoir le fournir à notre opérateur.


leni


Le 12/12/2019 à 21:13, Philippe Verdy - verd...@wanadoo.fr a écrit :
Non justement, aucun message d'erreur n'est expédié, le message est 
perdu directement et complètement silencieusement.


Le jeu. 12 déc. 2019 à 20:24, > a écrit :


Le 12/12/2019 à 17:55, Philippe Verdy - verd...@wanadoo.fr
 a écrit :

sinon ré"pondre à ces messages nous fera utiliser à nouveau
l'ancienne adresse qui ne sera plus reconnue alors qu'on est
pourtant bien abonné avec la nouvelle adresse avec laquelle on
répond.


Ceci est a priori un faux problème : la personne recevra un
message d'erreur et elle expédiera à la bonne adresse.

Certaines fois j'écris par erreur à talk-fr@openstreetmap.org
 avec mon adresse primaire et
osm.sanspourriel.5b67531659.talk-fr#talk-fr@openstreetmap.org

pour que ça passe par SpamGourmet.

Du fait du message à talk-fr@openstreetmap.org
, je reçois bien un message de
talk-fr-ow...@openstreetmap.org
 signalant le problème
(car je ne suis pas abonné).

Jean-Yvon

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


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


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

Re: [OSM-legal-talk] use OSM data to select proprietary data

[Frederik Ramm]

Kathleen,

On 12.12.19 23:40, Kathleen Lu via legal-talk wrote:
> No, ODbL does not apply to any database that does not include OSM data.

Are you sure about this? Let me give an example:

> If I understand your usecase correctly, Matthais, you are essentially
> checking your list against OSM boundaries. If something is both on your
> list and within the OSM boundary, then you say 'yes, this goes on the
> secondary list.' Then you want to publish your secondary list. There is
> no OSM data in the secondary list so it is not a Derivative Database.

Let us assume I have a list of all streets in Germany with their
geometry, from a non-OSM source.

I want to divide these into two groups: streets that have at least one
pub, and streets that have no pub.

Using OSM information about the location of pubs, I count the number of
pubs along each street, allowing me to make the desired separation.

I end up with a database of "streets that have at least one pub". This
database does not include OSM data.

In my eyes, though, it is still *derived* from OSM data. It is the
result of an algorithmic process that has made use of OSM data; if you
will, the OSM data residue is in the name/description of my new
database: "roads with pubs". It is derived from OSM; it could not have
been made without OSM.

Do you disagree?

Bye
Frederik

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

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

Re: [OSM-talk] OSM very old data

[Tom Ka]

Just few final notes (mainly for list archive):

- oldest usable .osm file is from 2006-04-03. Those old files have
plenty of nodes and ways (segments), but very few tagged, so only
geometry is there.
(https://planet.openstreetmap.org/cc-by-sa/planet-060403-fromARobinson.osm.7z)
- The oldest object in CZ (one of my goals) with proof of history is
from 2005-08-15: https://www.openstreetmap.org/node/172533/history
(lowest id is 172510 from the same edit - can be seen in 2006-08-18
data, but it's not in .osc files)
- There is no complete history before 2006-04-03. There are change
files (.osc) per day starting from 2005-04-17 but without initial .osm
to start with, they are of limited use (but contain timestamp and some
user info, used to identify node 172533).
(https://planet.openstreetmap.org/cc-by-sa/history/2005/0417-0418.osc.gz)
- I tried to have a look on fosm.org (those old data are the same),
but seems they do not have old history either.

Thanks for all the support here.
tom.k

čt 12. 12. 2019 v 14:29 odesílatel Tom Ka  napsal:
>
> Hi,
>
> successfully processed all data from cc-by-sa folder up to 2006-04-03.
> All results in v0.6 are available here:
>
> https://osm.fit.vutbr.cz/extracts/
>
> Bye tom.k
>
> čt 5. 12. 2019 v 13:03 odesílatel Tom Ka  napsal:
> >
> > Just to note - most of these old (v0.3) data have errors in UTF-8
> > encoding in some tag values (mainly name).
> >
> > Bye tom.k
> >
> > so 30. 11. 2019 v 13:09 odesílatel Tom Ka  napsal:
> > >
> > > Final v0.6 extracts for planet are available here:
> > >
> > > http://osm.fit.vutbr.cz/extracts/
> > >
> > > Will prepare some info about the process for others.
> > >
> > > Thanks to all, who helped.
> > >
> > > pá 29. 11. 2019 v 11:05 odesílatel Frederik Ramm  
> > > napsal:
> > > >
> > > > Hi,
> > > >
> > > > On 29.11.19 10:43, Tom Ka wrote:
> > > > > What it
> > > > > the meaning - deleted segments, so should I ignore those ways?
> > > >
> > > > I guess so.
> > > >
> > > > > 2) from 061205 the size increases, so I guess it contain some
> > > > > reasonable data, but for older (planet-061128.osm.bz2 -
> > > > > planet-060818.osm.bz2  ) there is size jump, which is strange. Is
> > > > > there any reason for this?
> > > >
> > > > Possibly https://wiki.openstreetmap.org/wiki/Old_TIGER_Import_2005/2006
> > > >
> > > > Bye
> > > > Frederik
> > > >
> > > > --
> > > > Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
> > > >
> > > > ___
> > > > talk mailing list
> > > > talk@openstreetmap.org
> > > > https://lists.openstreetmap.org/listinfo/talk

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

Re: [talk-cz] [osm_sk] Re: Historie OSM v CZ

[Tom Ka]

pá 13. 12. 2019 v 9:16 odesílatel Peter Misovic
 napsal:
>
> Ahoj, mne to nefunguje mimo Ciech. Cache som vymazal.
> Mam urobit este nieco?

je to jen pro CZ, viz SUBJ a dotaz, jestli nekdo stoji i o SK (je to
docela dost prace)

Bye tom.k

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

Re: [talk-cz] Historie OSM v CZ

[Tom Ka]

Ahoj,

Hotovo.

- nejstarsi pouzitelny OSM soubor je z 2006.04.03. U techto hodne
starych je dost uzlu i nejake cesty, ale minimum ma nejake tagy. Videt
jsou tak napr. mosty pri max. priblizeni (jen jmeno):  Karluv most a
okoli - https://osm.fit.vutbr.cz/cz_old/2006-04-03/15/17695/11100.png
- prokazatelne nejstarsi dohledatelny uzel v CZ je podle vseho z
2005-08-15: https://www.openstreetmap.org/node/172533/history
  (podle cisla uzlu je nejstarsi zreme
https://www.openstreetmap.org/node/172508 kousek vedle, ale k tomu jiz
starsi historicka data nejsou)
- OSM bohuzel nema k dispozici starsi historii, proste to tenkrat
nikdo neschoval, coz je trochu skoda. Jsou k dispozici zmenove soubory
po dni od 2005.04.17 ale neni k nim pocatecni OSM, takze jejich
pouziti je velmi omezene (napr. se podle nich dat urcit ten uzel
172533).

Tak se nam z ukolu do hry pro OpenAlt vyklubala docela zajimava "zabava" :-)

Bye tom.k

po 9. 12. 2019 v 8:39 odesílatel Tom Ka  napsal:
>
> Ahoj,
>
> na adrese https://kasparkovi.net/osm/ najdete dalsi varku starych
> verzi OSM mapy, aktualne az do 2007.05 a jeste jich par pribude!
>
> (Dotaz na Slovensko, mel by nekdo zajem o to same pro SK - at jiz
> extra nebo rozsireni stavajici mapy?)
>
> (A dotaz na Zbyho pripadne na ostatni - dobrovolnik na vylepseni
> rozhrani pro prohlizeni starych vrstev?)
>
> Bye tom.k

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