date:20191212

čt 12. 12. 2019 v 15:31 odesílatel Martin Koppenhoefer
 napsal:
>
> Very interesting! The timestamps are not valid (quite often there is a time 
> tag, which seems to be the GPG-logger time) and there is no user information 
> though. Also a lot of way ids are negative and all objects are in version 1. 
> Are these known limitations?
> I have only looked at v6-planet-060403.osm.bz2 so far

Timestamps have to be added where missing for following processing to
work (I use 2000-01-01 so you can see, what's artificial timestamp).
User info is missing in source v0.3 as well (but was not necessary for
processing to v0.6 so I did not add any dumb value). Version
information was not modified by me, and negative way ids are from the
04to05.pl script (segments to ways). Will publish the worksflow in a
diary soon, so anyone can check/repeat it.

Bye tom.k

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

Re: [OSM-talk] SOTM 2012 T-shirt

2019-12-12 Diskussionsfäden Nick Hocking

Many thanks Satoshi IIDA, We (Canberra Cavalry) have quite a few Japanese
players in our team this year, mainly pitchers. Tonight should be a good
night and the Japanese ambassador to Australia will be there. I only hope
he doesn't want my t-shirt :-) Cheers form Canberra Australia Nick
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] SOTM 2012 T-shirt

2019-12-12 Diskussionsfäden Satoshi IIDA

Hello from Japan.

The text in vertical lines are "七十億総伊能化 / Ino-rize 7 Billion people", means
the population of whole world.
And horizontal line, "一億 / 100 Million", means Japanese population = all of
Japan.

伊能/Ino is the most famous historical mapper in Edo-era.
He made a map of whole Japan by walking.
https://en.wikipedia.org/wiki/In%C5%8D_Tadataka

So the text says "Let's make every human being Mappers".
Thank you for wearing it since 2012!!

Best regards,


2019年12月13日(金) 14:05 Nick Hocking :

> Can anyone, who was at SOTM 2012 tell me what the inscription on the front
> of the T-shirt says.
>
> I'm going to wear mine tonight at a "Japanese Night" at the Baseball and
> anyone from Japan who is there is bound to come up and ask me about it.
>
> I know it starts of "70 Million people can't be wrong.
>
> An then I think it references a famous mapper in Japan who walked the
> llength an breadth of Japan in order to map it, many moons ago.  School
> children used to be taught him, but I can't remember his name.
>
> PS - chinese people are really confused about it - I think in their
> language it means something like "hey - I've got 70 million dollars!"  :-)
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>


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

[OSM-talk] SOTM 2012 T-shirt

2019-12-12 Diskussionsfäden Nick Hocking

Can anyone, who was at SOTM 2012 tell me what the inscription on the front
of the T-shirt says.

I'm going to wear mine tonight at a "Japanese Night" at the Baseball and
anyone from Japan who is there is bound to come up and ask me about it.

I know it starts of "70 Million people can't be wrong.

An then I think it references a famous mapper in Japan who walked the
llength an breadth of Japan in order to map it, many moons ago.  School
children used to be taught him, but I can't remember his name.

PS - chinese people are really confused about it - I think in their
language it means something like "hey - I've got 70 million dollars!"  :-)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

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 proche) obéit à une autre logique de
> > classification, où la commune n'est qu'un indicateur à une date donnée
> > (non précisée par le code lui-même).
> > De plus ce n'erst pas parce qu'une comune a cessé d'être de plein
> > exercice que son code disparit tout de suite, étant donné que l'INSEE
> > doit conserver les rapprochements statistiques d'une année sur

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

2019-12-12 Diskussionsfäden Jérôme Amagat

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-au] Experiments in sub meter accuracy for under $30 (thirty) dollars

2019-12-12 Diskussionsfäden Alex Sims

Hi,

I have been trying for some time to get better accuracy for survey mapping and 
think I might now be on to something. I’ve just got off the phone with Chris 
Marshall from Frontier SI who is promoting the use of the Geoscience SBAS test 
bed and was really helpful

I’m now armed with a Ublox M8030 USB dongle (birthday present, Chinese 
manufacturer, appears genuine at least from the boot messages etc) and 
instructions on key points in configuring it in u-center.

I’m hoping to get sub meter accuracy,  which should be possible as long as I 
can see the SBAS satellite.

Failing that I’ll wait for the Xiaomi Mi8, with dual band (1&5) to fall in 
price to be within my grasp

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

[OSM-talk] Support OSM communities in Bolivia, Iraq, Peru, Philippines, Sierra Leone, and South Sudan

2019-12-12 Diskussionsfäden Tyler Radford

HI all-
Six OpenStreetMap communities (in Bolivia, Iraq, Peru, Philippines, Sierra
Leone, and South Sudan) are raising funds this year for some pretty amazing
OpenStreetMap projects - from getting a community started for the first
time in South Sudan to mapping for mental health awareness in the
Philippines.

HOT is helping promote their campaigns. So - on behalf of all six
communities, could you help support with a donation by Dec. 31 and/or share
on social media? (use #MapTheDifference)

Check them out here:
https://pages.donately.com/hotosm/campaigns/

You can choose which community project to support and 100% of funds raised
for each project get transferred directly to that community in January. As
the projects progress you'll get updates directly from the community.

Let me know if you have questions and hoping we can all come together this
holiday season to help out in whatever way is possible for you.
Tyler

*Tyler Radford*
Executive Director
tyler.radf...@hotosm.org
@TylerSRadford

*Humanitarian OpenStreetMap Team*
*Using OpenStreetMap for Humanitarian Response & Economic Development*
web  | twitter  | facebook
 | donate

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

Re: [Talk-at] Windy Map

2019-12-12 Diskussionsfäden Rudolf Mayer


On 12/12/2019 18:55, Stefan Tauner wrote:

On Thu, 12 Dec 2019 18:42:37 +0100
Robert Grübler  wrote:


Die Erkennbarkeit hat sich merklich verbessert, aber gut ist sie weiterhin 
nicht.


Von gänzlich unsichtbar auf nicht bemerkbar (ich hab heute zum 1. Mal
drauf geschaut und obwohl ich wußte, dass es da ist mehrere Sekunden
gebraucht... von lesen können red ich da noch nicht).
Aber du hast insofern recht, als dass die einfach grundsätzlich nix von
Design verstehen dürften und das nicht gegen OSM gerichtet ist. ;)



Aber irgendwie ist es schon eine Verarng.

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..


Ich finde es nicht ok dass sie so tun als wäre es Ihnen wichtig, aber 
dann so eine "Verbesserung" zu machen..


Lg
Rudi

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

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

2019-12-12 Diskussionsfäden Kathleen Lu via legal-talk

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 
wrote:

> does contain derivate however,which means license applies
>
> On Thu, 12 Dec 2019, 19:46 ,  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-it] Errore per link dinamico di Overpass turbo per umap

2019-12-12 Diskussionsfäden Volker Schmidt

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

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

2019-12-12 Diskussionsfäden deuzeffe

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 proche) obéit à une autre logique de 
classification, où la commune n'est qu'un indicateur à une date donnée 
(non précisée par le code lui-même).
De plus ce n'erst pas parce qu'une comune a cessé d'être de plein 
exercice que son code disparit tout de suite, étant donné que l'INSEE 
doit conserver les rapprochements statistiques d'une année sur l'autre 
au moins pendant une période assez longue pour les usages réglementaires 
et les recours légaux possibles : les codes historiques persistent 
longtemps dans les fichiers et conservent leur validité, même si ce ne 
sont plus les codes premiers pour les données concernant les nouveaux 
exercices: ils restent donc réservés et normalement pas réaffectables 
avant très longtemps.
Le COG lui-même doit donc être millésimé en tant que référence, il n'est 
pas unique.


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


Le Code Officiel Géographique est ton ami.

HTH


___
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

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 proche) obéit à une autre logique de
classification, où la commune n'est qu'un indicateur à une date donnée (non
précisée par le code lui-même).
De plus ce n'erst pas parce qu'une comune a cessé d'être de plein exercice
que son code disparit tout de suite, étant donné que l'INSEE doit conserver
les rapprochements statistiques d'une année sur l'autre au moins pendant
une période assez longue pour les usages réglementaires et les recours
légaux possibles : les codes historiques persistent longtemps dans les
fichiers et conservent leur validité, même si ce ne sont plus les codes
premiers pour les données concernant les nouveaux exercices: ils restent
donc réservés et normalement pas réaffectables avant très longtemps.
Le COG lui-même doit donc être millésimé en tant que référence, il n'est
pas unique.

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

> Le Code Officiel Géographique est ton ami.
>
> HTH
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2019-12-12 Diskussionsfäden deuzeffe


Le 12/12/2019 à 22:12, Vincent de Château-Thierry a écrit :

Bonsoir,


Pareil,

D'après la description du fichier FANTOIR 
(https://www.data.gouv.fr/fr/datasets/r/7c52d813-1e98-4772-8a7a-6a01f9d30c6e 
) c'est 11. Sauf que le code direction - fiscale ? - (deuxième 
"champ") semble avoir été ràz, donc ignoré dans la version finale ?


Si quelqu'un y voit plus clair que moi...


Disons que dans OSM depuis au moins le début de BANO (mi 214) on a 
choisi de ne pas considérer ce code direction pour composer ce qu'on 
appelle le ref:FR:FANTOIR. C'est devenu "notre" convention, massivement 
appliquée depuis, et assez pratique puisqu'elle permet très simplement 
un lien avec la commune, vu que les 5 1ères positions du code 
correspondent au code INSEE communal. Je ne sais pas quel avantage / 
quelle interopérabilité nous apporterait l'inclusion du code direction 
en 3è position, je sais en revanche qu'il nous casserait bien les pieds 
à chaque tentative de rapprochement simple entre le code ref:FR:FANTOIR 
et sa commune d'appartenance. On passerait notre temps à détricoter le 
ref:FR:FANTOIR pour en virer le code direction. Un peu pénible...


Ah bin voilà, c'est parfait comme ça. Merci beaucoup !

Merci aussi pour l'icône "Télécharger en csv" ;)

--
deuzeffe - me coucherai moins ignorante.



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

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

2019-12-12 Diskussionsfäden deuzeffe


Le Code Officiel Géographique est ton ami.

HTH

Le 12/12/2019 à 22:19, Philippe Verdy a écrit :
Mais est-ce que ça marche pour Paris (un seul code commune comme 75000 
ou plusieurs, un par arrondissement 75101 à 75120) et Marseilles? Pas de 
doublon indésirables? Le dédoublonnage (renumérotation éventuelle) 
a-t-il déjà eu lieu dans les anciennes directions pour avoir des codes 
FANTOIR uniques par code commune (y compris les "communes nouvelles" ou 
récemment fusionnées en fusion simple) ?


Le jeu. 12 déc. 2019 à 22:13, Vincent de Château-Thierry 
mailto:osm.v...@free.fr>> a écrit :


Bonsoir,

Le 11/12/2019 à 21:53, deuzeffe a écrit :
 > Le 11/12/2019 à 05:10, Jérôme Amagat a écrit :
 >> Bonjour,
 >>
 >> D’après le wiki il faut 10 caractère dans ref:FR:FANTOIR=*
 >> https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
 >> Il y a beaucoup de valeurs pour ce tag qui compte 11 caractères :
 >> https://overpass-turbo.eu/s/OSX
 >
 > D'après la description du fichier FANTOIR
 >
(https://www.data.gouv.fr/fr/datasets/r/7c52d813-1e98-4772-8a7a-6a01f9d30c6e

 > ) c'est 11. Sauf que le code direction - fiscale ? - (deuxième
"champ")
 > semble avoir été ràz, donc ignoré dans la version finale ?
 >
 > Si quelqu'un y voit plus clair que moi...

Disons que dans OSM depuis au moins le début de BANO (mi 214) on a
choisi de ne pas considérer ce code direction pour composer ce qu'on
appelle le ref:FR:FANTOIR. C'est devenu "notre" convention, massivement
appliquée depuis, et assez pratique puisqu'elle permet très simplement
un lien avec la commune, vu que les 5 1ères positions du code
correspondent au code INSEE communal. Je ne sais pas quel avantage /
quelle interopérabilité nous apporterait l'inclusion du code direction
en 3è position, je sais en revanche qu'il nous casserait bien les pieds
à chaque tentative de rapprochement simple entre le code ref:FR:FANTOIR
et sa commune d'appartenance. On passerait notre temps à détricoter le
ref:FR:FANTOIR pour en virer le code direction. Un peu pénible...

vincent


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


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



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

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

Mais est-ce que ça marche pour Paris (un seul code commune comme 75000 ou
plusieurs, un par arrondissement 75101 à 75120) et Marseilles? Pas de
doublon indésirables? Le dédoublonnage (renumérotation éventuelle) a-t-il
déjà eu lieu dans les anciennes directions pour avoir des codes FANTOIR
uniques par code commune (y compris les "communes nouvelles" ou récemment
fusionnées en fusion simple) ?

Le jeu. 12 déc. 2019 à 22:13, Vincent de Château-Thierry 
a écrit :

> Bonsoir,
>
> Le 11/12/2019 à 21:53, deuzeffe a écrit :
> > Le 11/12/2019 à 05:10, Jérôme Amagat a écrit :
> >> Bonjour,
> >>
> >> D’après le wiki il faut 10 caractère dans ref:FR:FANTOIR=*
> >> https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
> >> Il y a beaucoup de valeurs pour ce tag qui compte 11 caractères :
> >> https://overpass-turbo.eu/s/OSX
> >
> > D'après la description du fichier FANTOIR
> > (
> https://www.data.gouv.fr/fr/datasets/r/7c52d813-1e98-4772-8a7a-6a01f9d30c6e
> > ) c'est 11. Sauf que le code direction - fiscale ? - (deuxième "champ")
> > semble avoir été ràz, donc ignoré dans la version finale ?
> >
> > Si quelqu'un y voit plus clair que moi...
>
> Disons que dans OSM depuis au moins le début de BANO (mi 214) on a
> choisi de ne pas considérer ce code direction pour composer ce qu'on
> appelle le ref:FR:FANTOIR. C'est devenu "notre" convention, massivement
> appliquée depuis, et assez pratique puisqu'elle permet très simplement
> un lien avec la commune, vu que les 5 1ères positions du code
> correspondent au code INSEE communal. Je ne sais pas quel avantage /
> quelle interopérabilité nous apporterait l'inclusion du code direction
> en 3è position, je sais en revanche qu'il nous casserait bien les pieds
> à chaque tentative de rapprochement simple entre le code ref:FR:FANTOIR
> et sa commune d'appartenance. On passerait notre temps à détricoter le
> ref:FR:FANTOIR pour en virer le code direction. Un peu pénible...
>
> vincent
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2019-12-12 Diskussionsfäden Vincent de Château-Thierry

OK pour ce message, mais il y a d'autres cas où aucun message n'est envoyé
en retour, nulle part (dans aucun dossier "spam" non plus); la liste ne
fonctionne pas (et cela pas seulement de façon temporaire, les messages ne
seront jamais transmis même plusieurs jours, semaines ou mois après), comme
cela était signalé en tête de ce fil de messages. Mystème complet mais cela
a débuté précisé le 12 mars dernier.

Le jeu. 12 déc. 2019 à 22:00,  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.
>
>
> 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 
> 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] ref:FR:FANTOIR


Bonsoir,

Le 11/12/2019 à 21:53, deuzeffe a écrit :

Le 11/12/2019 à 05:10, Jérôme Amagat a écrit :

Bonjour,

D’après le wiki il faut 10 caractère dans ref:FR:FANTOIR=* 
https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR

Il y a beaucoup de valeurs pour ce tag qui compte 11 caractères :
https://overpass-turbo.eu/s/OSX


D'après la description du fichier FANTOIR 
(https://www.data.gouv.fr/fr/datasets/r/7c52d813-1e98-4772-8a7a-6a01f9d30c6e 
) c'est 11. Sauf que le code direction - fiscale ? - (deuxième "champ") 
semble avoir été ràz, donc ignoré dans la version finale ?


Si quelqu'un y voit plus clair que moi...


Disons que dans OSM depuis au moins le début de BANO (mi 214) on a 
choisi de ne pas considérer ce code direction pour composer ce qu'on 
appelle le ref:FR:FANTOIR. C'est devenu "notre" convention, massivement 
appliquée depuis, et assez pratique puisqu'elle permet très simplement 
un lien avec la commune, vu que les 5 1ères positions du code 
correspondent au code INSEE communal. Je ne sais pas quel avantage / 
quelle interopérabilité nous apporterait l'inclusion du code direction 
en 3è position, je sais en revanche qu'il nous casserait bien les pieds 
à chaque tentative de rapprochement simple entre le code ref:FR:FANTOIR 
et sa commune d'appartenance. On passerait notre temps à détricoter le 
ref:FR:FANTOIR pour en virer le code direction. Un peu pénible...


vincent


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

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

2019-12-12 Diskussionsfäden osm . sanspourriel


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.


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, mailto:osm.sanspourr...@spamgourmet.com>> 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

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

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

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

2019-12-12 Diskussionsfäden Nuno Caldeira

does contain derivate however,which means license applies

On Thu, 12 Dec 2019, 19:46 ,  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

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

Let me get into detail is this project to proof that this case isn't constructed.

We've purchased geodata with real estate prices (houses & flats) for Germany's federal state "Northrhine Westfalia". Each row has coordinates in WGS84. The TOS of the purchhased dataset state, that it's not allowed to relicense the pricing data or the coordinates under another license. So we can't go ODbL here.

We want to extract postcode areas (more than 100 nodes) from the OSM database and merge them into sensefull peaces, like market regions. Of course, we can release those new areas, since they're clearly ODbL.

Using this market regions, we would like to calculate the average housing and flat prices and display them on a map. We also would like to display the exact position on a new layer (not mixed with OSM data).

I've seen plenty of websites displaying such prices, especially newspapers. All were based on Mapbox or Carto.

Gesendet: Donnerstag, 12. Dezember 2019 um 20:31 Uhr
Von: "Simon Poole"
An: legal-talk@openstreetmap.org
Betreff: Re: [OSM-legal-talk] use OSM data to select proprietary data

Yes, if a Derivative Database was created in the first place, and that is not clear at all, see:

“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.

Essentially the question is if the envelopes of the extracted points are a substantial extract of our data (because they represent the residual information/data from OSM), while it is obviously possible to construct cases were this would be the case, in the typical relatively sparse POI scenario I don't quite see that.

I don't particularly like engaging in these discussion because they tend to end up being arguments about how many angels can stand on a pin and are not answerable outside of the detailed specifics of the actual use case (which are typically not available).

Simon

Am 12.12.2019 um 20:05 schrieb Nuno Caldeira:

https://opendatacommons.org/licenses/odbl/1.0/index.html

the license is quite clear and 4.2 applies to the case you mention. any use of OSM data (over 100 nodes) combined with proprietary data results in more open data under ODbL.

we are here to create more open data, not to feed proprietary data than is lock under their TOS.

On Thu, 12 Dec 2019, 18:53 , wrote:

> From a practical point of view, boundaries in OSM rarely originate from surveys,
> you might be lucky to be able to identify the original source (most likely open data)
> which may have a more liberal license than ODbL (check the history and changeset
> source tags / object source tags).

But I neither want to merge OSM data or add it to my data. I just want to use it to
select points of my dataset.

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

___legal-talk mailing listlegal-talk@openstreetmap.orghttps://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

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

> 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

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

2019-12-12 Diskussionsfäden Simon Poole

Yes, if a Derivative Database was created in the first place, and that
is not clear at all, see:

/“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./

Essentially the question is if the envelopes of the extracted points are
a substantial extract of our data (because they represent the residual
information/data from OSM), while it is obviously possible to construct
cases were this would be the case, in the typical relatively sparse POI
scenario I don't quite see that.

I don't particularly like engaging in these discussion because they tend
to end up being arguments about how many angels can stand on a pin and
are not answerable outside of the detailed specifics of the actual use
case (which are typically not available).

Simon

Am 12.12.2019 um 20:05 schrieb Nuno Caldeira:
> https://opendatacommons.org/licenses/odbl/1.0/index.html
> the license is quite clear and 4.2 applies to the case you mention.
> any use of OSM data (over 100 nodes) combined with proprietary data
> results in more open data under ODbL. 
> we are here to create more open data, not to feed proprietary data
> than is lock under their TOS. 
>
> On Thu, 12 Dec 2019, 18:53 ,  > wrote:
>
> > From a practical point of view, boundaries in OSM rarely
> originate from surveys,
> > you might be lucky to be able to identify the original source
> (most likely open data)
> > which may have a more liberal license than ODbL (check the
> history and changeset
> > source tags / object source tags).
>
> But I neither want to merge OSM data or add it to my data. I just
> want to use it to
> select points of my dataset.
>
> ___
> 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

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

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

2019-12-12 Diskussionsfäden osm . sanspourriel


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
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

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

Am Do., 12. Dez. 2019 um 19:53 Uhr schrieb <
matthias.straetl...@buerotiger.de>:

> But I neither want to merge OSM data or add it to my data. I just want to
> use it to
> select points of my dataset.



then it may eventually fall under the geocoding guideline:
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Geocoding_-_Guideline

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

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

Am Do., 12. Dez. 2019 um 18:46 Uhr schrieb Robert Grübler <
robgrueb...@gmail.com>:

>
> Gegenüberstellung:
> https://abload.de/img/omm_windy_cpr2mhk8x.jpg
>
> Die Erkennbarkeit hat sich merklich verbessert, aber gut ist sie weiterhin
> nicht. Dennoch bin ich geneigt es zu akzeptieren, da die eigenen Menüpunkte
> denselben, schlecht leserlichen, Style verwenden.
> Ich schlage vor den Windy-Map-Issue in
> https://wiki.openstreetmap.org/wiki/Lacking_proper_attribution von notOK
> auf OK zu setzen.
>
> Einverstanden?
> (Das betrifft nur die Desktop-App. Zur mobilen-App kann ich nichts sagen,
> weil ich sie nicht kenne)



ich finde die Attibution auch nach wie vor nicht erkennbar, stimme Dir aber
zu, ihre eigenen Menus sind auch nicht lesbar. Ich würde von notOK auf fast
OK sagen ;-)
also +0,95

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

Re: [Talk-ca] Parc des Ïles de Boucherville

2019-12-12 Diskussionsfäden Pierre Béland via Talk-ca

Pierre,
Je ne sais pas si tu voulais dessiner un circuit pour pédalos :-)

Il y a plusieurs iles et marécages autour de l'archipel de Boucherville.  Et 
Martin a aussi édité le secteur.
 Il existe déja Chemin : 77938080    "natural"="wetland"
plus un autre à l'intérieur qui décrit une ile.
Il existait aussi une Île de la Commune que j'ai conservé et ajouter avec rôle 
inner dans relation eau (puis enlever lien pour chemins ci-dessous).

Tu as créé deux nouveaux Chemins que j'ai effacé
 Île de la Commune (40616848)
    "name"="Île de la Commune" qui correspond à l'ïle qui existait déja

Puis tu as créé une deuxième instance de l'Île cette fois-ci englobant 
plusieurs Îles.
 : Île de la Commune (653906078)    "name"="Île de la Commune"

J'ai corrigé rapidement - Petits messages d'erreurs sur les rôles dans relation 
eau que je vérifierai ce soir. Je dois maintenant m'absenter.


 
Pierre 
 

Le jeudi 12 décembre 2019 13 h 29 min 00 s UTC−5, Pierre Béland via Talk-ca 
 a écrit :  
 
 Ce que je vois à partir de JOSM, il y a doublons- 3 chemins superposés pour 
décrire le contour de l'ile

Je suis a corriger. attendre avant d'éditer a nouveau.
 
Pierre 

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

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

2019-12-12 Diskussionsfäden Nuno Caldeira

https://opendatacommons.org/licenses/odbl/1.0/index.html
the license is quite clear and 4.2 applies to the case you mention. any use
of OSM data (over 100 nodes) combined with proprietary data results in more
open data under ODbL.
we are here to create more open data, not to feed proprietary data than is
lock under their TOS.

On Thu, 12 Dec 2019, 18:53 ,  wrote:

> > From a practical point of view, boundaries in OSM rarely originate from
> surveys,
> > you might be lucky to be able to identify the original source (most
> likely open data)
> > which may have a more liberal license than ODbL (check the history and
> changeset
> > source tags / object source tags).
>
> But I neither want to merge OSM data or add it to my data. I just want to
> use it to
> select points of my dataset.
>
> ___
> 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

> From a practical point of view, boundaries in OSM rarely originate from 
> surveys,
> you might be lucky to be able to identify the original source (most likely 
> open data)
> which may have a more liberal license than ODbL (check the history and 
> changeset
> source tags / object source tags).

But I neither want to merge OSM data or add it to my data. I just want to use 
it to
select points of my dataset.

___
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

Hi,

> when you write „number of boundaries“, you intend „boundary points“?

No, for example postcodes. I want to merge some of them to new polygons.

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

2019-12-12 Diskussionsfäden Martin Chalifoux via Talk-ca

Hi,

> In my NAL opinion, the result will be derived from OSM data and
> therefore inherits the ODbL license. This does, however, not mean that
> you have to publish it; but *if* you publish (or "publilcy use") it,
> then it has to be available under ODbL. If you just use it internally
> then it is still ODbL but that doesn't matter to you.

Oh wait. I don't want to publish the modified OpenStreetMap data.
I want to publish the proprietary dataset, which I've selected using the 
OpenStreetMap data.
For example, I want to select the non-free points using postcode polygons, 
derived from OpenStreetMap.

Regards,
Matthias

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

Re: [OSM-talk-fr] CA Physique

2019-12-12 Diskussionsfäden osm . sanspourriel


Pour que tu saches sans attendre plus : je ne serai pas des vôtres.

Bonne et fructueuse réunion.

Jean-Yvon

Le 12/12/2019 à 14:23, Tony Emery via Talk-fr -
talk-fr@openstreetmap.org a écrit :
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-ca] Parc des Ïles de Boucherville

2019-12-12 Diskussionsfäden Pierre Béland via Talk-ca

Ce que je vois à partir de JOSM, il y a doublons- 3 chemins superposés pour 
décrire le contour de l'ile

Je suis a corriger. attendre avant d'éditer a nouveau.
 
Pierre 
 

Le jeudi 12 décembre 2019 12 h 23 min 42 s UTC−5, Martin Chalifoux via 
Talk-ca  a écrit :  
 
 Tu as sans doute cassé des relations. La relation du fleuve st-laurent est 
très complexe et personne devrait jouer avec. Comme on dit, if it works don’t 
fix it. Je pense que quelqu’un est en train de corriger, alors je vais pas 
jouer dedans pour le moment. Si ce-soir c'est pas corrigé je vais jeter un coup 
d’oeil.


On Dec 12, 2019, at 12:11 , Pierre Boucher  wrote:
 
 Bonjour,
 
 Certaines îles du Parc des Îles de Boucherville n'apparaissent pas sur la 
carte...
 Île de la Commune
 Île à Pinard
 Île Saint-Jean
 J'ai essayé de corriger la situation mais sans succès.  Quelqu'un peut-il 
corriger et/ou m'expliquer...
 
 https://www.cyclosm.org/#map=13/45.6068/-73.4803/cyclosm
 
  Joyeuses Fêtes
 
 Boff II
 
Pierre Boucher
 
 
...Pensez à l'environnement avant d'imprimer ce courriel !.
 
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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

Re: [Talk-at] Windy Map

2019-12-12 Diskussionsfäden Stefan Tauner

On Thu, 12 Dec 2019 18:42:37 +0100
Robert Grübler  wrote:

> Die Erkennbarkeit hat sich merklich verbessert, aber gut ist sie weiterhin 
> nicht.

Von gänzlich unsichtbar auf nicht bemerkbar (ich hab heute zum 1. Mal
drauf geschaut und obwohl ich wußte, dass es da ist mehrere Sekunden
gebraucht... von lesen können red ich da noch nicht).
Aber du hast insofern recht, als dass die einfach grundsätzlich nix von
Design verstehen dürften und das nicht gegen OSM gerichtet ist. ;)

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

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

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

2019-12-12 Diskussionsfäden Etienne Trimaille

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

> Je n'utilise pas quickOSM car les données sont déjà dans Postgresql via
> osm2pgsql.
>

Ah, mais on ne savait pas ;-)

Ttraite le HStore dans Postgresql directement alors?
Lors de ta requête. Cela sera plus efficace que de le faire dans QGIS.

https://www.postgresql.org/docs/10/hstore.html

Peut-être faire une vue matérialisé ou des index. À voir dans ton cas
précis.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2019-12-12 Diskussionsfäden Robert Grübler

robhubi schrieb am Freitag, 15. November 2019 22:21

> Sehr schön, die Entwickler haben reagiert:
> https://community.windy.com/topic/3353/map-correction/15 

Die adaptierte Attributierung ist nun auch auf der Webseite zu sehen: 
https://www.windy.com/?47.052,15.469,18 

Attributierung  vorher:
"(C) OSM & contributors" – Schrift: 8px, weiß, mit 70% Transparenz

Attributierung  nachher:
„© OpenStreetMap contributors“ - Schrift: 10px, fast weiß, voll deckend

Gegenüberstellung:
https://abload.de/img/omm_windy_cpr2mhk8x.jpg 

Die Erkennbarkeit hat sich merklich verbessert, aber gut ist sie weiterhin 
nicht. Dennoch bin ich geneigt es zu akzeptieren, da die eigenen Menüpunkte 
denselben, schlecht leserlichen, Style verwenden.
Ich schlage vor den Windy-Map-Issue in 
https://wiki.openstreetmap.org/wiki/Lacking_proper_attribution von notOK auf OK 
zu setzen.

Einverstanden?
(Das betrifft nur die Desktop-App. Zur mobilen-App kann ich nichts sagen, weil 
ich sie nicht kenne)

Liebe Grüße
Robert (robhubi)



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

Re: [Talk-at] Windy Map

2019-12-12 Diskussionsfäden Robert Grübler

robhubi schrieb am Freitag, 15. November 2019 22:19

> Sehr schön, die Entwickler haben reagiert:
> https://community.windy.com/topic/3353/map-correction/15 

Die adaptierte Attributierung ist nun auch auf der Webseite zu sehen: 
https://www.windy.com/?47.052,15.469,18 

Attributierung  vorher:
"(C) OSM & contributors" – Schrift: 8px, weiß, mit 70% Transparenz

Attributierung  nachher:
„© OpenStreetMap contributors“ - Schrift: 10px, fast weiß, voll deckend

Gegenüberstellung:
https://abload.de/img/omm_windy_cpr2mhk8x.jpg 

Die Erkennbarkeit hat sich merklich verbessert, aber gut ist sie weiterhin 
nicht. Dennoch bin ich geneigt es zu akzeptieren, da die eigenen Menüpunkte 
denselben, schlecht leserlichen, Style verwenden.
Ich schlage vor den Windy-Map-Issue in 
https://wiki.openstreetmap.org/wiki/Lacking_proper_attribution von notOK auf OK 
zu setzen.

Einverstanden?
(Das betrifft nur die Desktop-App. Zur mobilen-App kann ich nichts sagen, weil 
ich sie nicht kenne)

Liebe Grüße
Robert (robhubi)




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

Re: [Talk-ca] Parc des Ïles de Boucherville

Tu as sans doute cassé des relations. La relation du fleuve st-laurent est très 
complexe et personne devrait jouer avec. Comme on dit, if it works don’t fix 
it. Je pense que quelqu’un est en train de corriger, alors je vais pas jouer 
dedans pour le moment. Si ce-soir c'est pas corrigé je vais jeter un coup 
d’oeil.

> On Dec 12, 2019, at 12:11 , Pierre Boucher  wrote:
> 
> Bonjour,
> 
> Certaines îles du Parc des Îles de Boucherville n'apparaissent pas sur la 
> carte...
> Île de la Commune
> Île à Pinard
> Île Saint-Jean
> J'ai essayé de corriger la situation mais sans succès.  Quelqu'un peut-il 
> corriger et/ou m'expliquer...
> 
> https://www.cyclosm.org/#map=13/45.6068/-73.4803/cyclosm 
> 
> 
>  Joyeuses Fêtes
> 
> Boff II
> Pierre Boucher
> 
> ...Pensez à l'environnement avant d'imprimer ce courriel !.
> 
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca

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

[Talk-ca] Parc des Ïles de Boucherville

2019-12-12 Diskussionsfäden Pierre Boucher


Bonjour,

Certaines îles du Parc des Îles de Boucherville n'apparaissent pas sur 
la carte...

Île de la Commune
Île à Pinard
Île Saint-Jean
J'ai essayé de corriger la situation mais sans succès.  Quelqu'un 
peut-il corriger et/ou m'expliquer...


https://www.cyclosm.org/#map=13/45.6068/-73.4803/cyclosm

 Joyeuses Fêtes

Boff II

*/Pierre Boucher/*



*...Pensez à l'environnement avant d'imprimer ce courriel !.*

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

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

2019-12-12 Diskussionsfäden HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE PPE)

Il y a une autre raison: lorsqu'on envoie un mail à la liste, celle-ci
tente d'identifier si l'utilisateur est abonné. Si on s'est inscrit
initialement avec une adresse NOM@DOMAINE1 et que maintenant on a changé de
fournisseur mail, et redirigé les messages, on continue de recevoir les
messages de la liste. Et normalement ces messages reçus mentionnent dans
les entêtes le chemin suivi (y compris la redirection) et le chemin devrait
être repris dans un client mail quand on répond à la liste via ce message.

Mais le serveur de la liste voit un message venant d'un fournisseur SMTP
différent de celui d'origine sur un autre DOMAINE2. Il tente de vérifier
que l'expéditeur NOM@DOMAINE1 indiqué dans la réponse se conencte bien d'un
serveur de DOMAINE1, hors la réponse vient d'un fournisseur DOMAINE2 qui ne
correspond pas à DOMAINE1. Le serveur de la liste doit alors tenter
d'aurthentifier le chemin suivi en vérifiant les entêtes MIME. Mais bien
qu'ils soient en tout point conforme aux entêtes émis par le fournisseur de
liste, et que le chemion de réponse fait le chemin inverse des domaines, il
est très pointilleux et tente de vérifier la confiance entre chacun des
sauts. Mais il échoue car les serveurs de messagerie ont souvent des
"sauts" internes via des adresses IP privées que le serveur de liste ne
peut pas vérifier et il ne semble pas aller plus loin pour repérer que le
serveur d'entrée et le serveur de sortie sont bien dans les bons domaines
et avec des IP publiques authentifiées.

Malheuseument l'authentification des domaines suit des tas de règles
différentes (secure DNS, inscriptions de champs TXT dans plusieurs formats
selon ce qu'exige Google ou d'autres, et il n'y a pas d'accord complet
entre les différents fournisseurs.

Ici il semble qu'OSM a changé son logiciel de gestion de listes et que le
nouveau ne connait pas certaines règles de vérification de domaines ou bien
a un bogue dans l'analyse des entêtes MIME. Cela aboutit à un échec, le
message de réponse reçu par la liste est accepté mais ne va pas plus loin,
il est simplement jeté, et aucun retour n'est fait à l'émetteur de la
réponse.

Le problème est qu'on ne sait généralement pas quand on répond à un message
quel chemin a été suivi. Et ces chemins changent avec le temps et aucune
garantie que le chemin suivi par les mails envoyés par la lsite et ceux de
nos réponses vers la liste suivent les mêmes domaines : ce n'est en fait
généralement plus le cas depuis longtemps et diverses techniques ont été
utilisées, pas toujours équivalentes,  mais nécessaitant chacune des
méthodes de vérification différentes. Visiblement il y a eu un retour en
arrière avec le gestionnaire de listes.

Noter aussi que cela correspond à l'entrée en vigueur de règles plus
strictes par Google pour les listes de diffusion au printemps dernier, puis
cela a suivi dans le désordre dans différentes autres sites, qui auraient
du se mettre à jour pour comprendre les nouvelles règles.

Le serveur de listes a pu également expérimenter un certain nombre de
"bounces" avec nos anciennes adresses redirigées, et pour faire le ménage
et éviter la saturation de son espace de stockage a pu décider d'éliminer
massivement les adresses en défaut pendant une période trop prolongée : ces
messages de la liste ne sont donc plus remis du tout alors qu'on y est
toujours abonné théoriquement:
le serveur de listes d'OSM oublie de faire des vérifications régulières de
nos accès en adressant un mail par mois de rappel pour gérer nos
inscriptions et revalider les chemins suivis et éviter les "bounces"
prolongés qui saturent son espace de stockage de mails en attente de
diffusion.

Quelquechose a donc bien eu lieu en mars dernier: soit l'absence d'une mise
à jour nécessaire pour pouvoir continuer à envoyer à certains fournisseurs
de messagerie et authentifier les chemins avec les nouvelles méthodes, soit
un changement de logiciel chez OSM avec un logiciel en fait moisn
performant et bogué. Gérer un serveur de diffusion de listes est compliqué,
les bons logiciels qui font ça bien ne sont pas légion, et ild fonctionnent
dans des configurations très précises des systèmes internes et frontaux du
serveur qui l'héberge: ce devrait être un serveur dédié à ça tellement
c'est "casse-gueule" (et avec des configs de caches, DNS, outils antispams
eux aussi à jour, y compris les DNSBL tiers nécessaires qui nécessitent
souvent aussi un abonnement actif pour rester à jour des règles, et aussi
joignables : un parefeu frontal mal reconfiguré peut bloquer les requêtes
DNSBL et produire alors des faux positifs et des rejets inattendus).

Dans l'immédiat il n'y a qu'une solution pour qu'OSM admette nos réponses
et nous reconnaissent : créer un second compte d'abonné aux listes avec la
nouvelle adresse mail. pour que le serveur accepte aussi bien l'ancienne
adresse mail que la nouvelle et nous reconnaisse (pour le reste cela poste
un problème car on est abonné deux fois et cela peut faire qu'on reçoive
les messages de la

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

Salut Tony,

Essaie ceci :
Dans ton projet tu définis une (ou plusieurs) variable(s) dont la valeur est le 
nom de la clé que tu veux extraire
champ : 'building' par exemple
Dans ta couche de données osm, ajoute un champ virtuel de type texte (ou autre 
suivant besoin) qui contient la formule : map_get( tags,  @champ  ) où tags est 
le champ qui contient ton hstore
Qgis mettra dans ta colonne virtuelle la valeur de la clé dont le nom est 
spécifié par la variable.
Il te suffira de changer la valeur de la variable pour changer de clé à 
extraire. 
Tu peux faire autant de champs virtuels que tu veux pour extraire plusieurs clés

J'espère que cela répondra à ton besoin
Denis

-Message d'origine-
De : Tony Emery via Talk-fr  
Envoyé : jeudi 12 décembre 2019 13:56
À : talk-fr@openstreetmap.org
Cc : Tony Emery 
Objet : Re: [OSM-talk-fr] gestion du hstore dans qgis

Je n'utilise pas quickOSM car les données sont déjà dans Postgresql via 
osm2pgsql.

Mon problème est que si je demande à osm2pgsql d'extraire tous les champs (via 
le fichier de config), je vais en avoir beaucoup dont la majorité sera vide et 
cela rendra mes requêtes futures compliquées à gérer.

Du coup, j'ai fait quelques requêtes post intrégration dans postgresql pour 
créer des tables thématiques (highway, landuse,...) à partir d'une table dans 
laquelle se trouvent la clés principale et toutes les clés à extraire.
Sauf que ces clés doivent être déjà extraite par osm2pgsql et si je veux en 
ajouter d'autres, c'est pas très souple.

J'avais pensé à mettre mon extracteur de hstore ( tags->'bridge' AS bridge ) 
dans la table mais les guillemets me font planter la requête.

Du coup, je me tourne vers qgis pour savoir si on peut faire des analyses carto 
en utilisant directement le champ "tags" contenant le hstore dans la sémiologie.



-
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
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it. 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2019-12-12 Diskussionsfäden marc marc



> 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.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2019-12-12 Diskussionsfäden FR via Talk-fr


Bonjour

Et bien je constate que mon alerte n’aura pas été inutile ;-) Les bonnes 
pratiques énoncées dans ce texte recoupent tout à fait en creux les bugs 
que j'ai pu constater.
J'espère seulement que le ou la prof des chiapacans qui nous ont mis le 
waï dans OSM (1) ne se formalise pas trop de cette aventure. D'une part 
il-elle essuie les plâtres d'une réforme des programmes dont les auteurs 
manifestement ne se sont pas demandé ce que ça impliquait de temps de 
prise en main pour des profs découvrant OSM. D'autre part ce n'est pas 
qu'à propos d’OSM que nos ados se défoulent : 
.


Quant aux corrections, elles sont en cours (22 contributions repérées). 
Personnellement j’ai priorisé de ce qui impactait les lignes de bus et 
le réseau ferré et je tente de récupérer ce qui a été effacé. Mais un 
"revert" aurait été un peu moins bouffe temps.


Il y a un problème avec certaines corrections faites avec iD par 
d'autres contributeurs. Elles ont abouti à la suppression d’objets 
faute de remonter à l'état précédent. Par ex. le chemin du 
"highway=service" qui avait été transformé en "railway" a été effacé.
Est-ce qu’il est possible avec iD de remonter dans l’historique comme on 
le fait avec JOSM, afin de récupérer les anciens attributs ainsi que les 
coordonnées des objets déplacés ? J'ai pas trouvé (mais je ne connais 
que JOSM).


FR

(1) si toutefois il se confirme qu'il s'agit bien d'un cours de SNT, 
après tout j'en sais toujours rien...



Le 11/12/2019 à 21:23, Cédric Frayssinet a écrit :
vous informe que suite aux mauvaises contributions marseillaises, un 
courriel est parti dans toutes les DANE (Délégation Académique au 
Numérique Éducatif) de France. Il a été envoyé ce matin et il devrait 
redescendre chez tous les enseignants de SNT en académie.


Je vous le mets pour info là : https://cloud.mesdatas.org/s/omfk7aoefegrHFA

Il a été validé par certaines membres du CA OSM-Fr et notamment Vincent 
Bergeot.


J'ai déjà été contacté, et notamment par un auteur du manuel Bordas qui 
avait vu arriver les soucis possibles.


Espérons que cela ait un effet positif, n'hésitez pas à remonter les 
éventuels soucis.


Cédric





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

Re: [OSM-talk] OSM very old data

Very interesting! The timestamps are not valid (quite often there is a time
tag, which seems to be the GPG-logger time) and there is no user
information though. Also a lot of way ids are negative and all objects are
in version 1. Are these known limitations?
I have only looked at v6-planet-060403.osm.bz2 so far

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

Re: [Talk-GB] HS2 camden updates

2019-12-12 Diskussionsfäden Andy Allan

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

Re: [OSM-talk] OSM very old data

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

[OSM-talk-fr] CA Physique

2019-12-12 Diskussionsfäden Tony Emery via Talk-fr

Bonjour à toutes et à tous,

Petit rappel !

Le prochain conseil d'administration physique (CAP) de l'association
OpenStreetMap France (OSM-FR) aura lieu les 15 et 16 février 2020 à la
Turbine à Grenoble. L'adresse est la suivante : 3-5 esplanade Andry Farcy,
38000 Grenoble.

Ce CAP n'est pas réservé qu'aux membres du conseil d'administration mais,
plus encore que l'an dernier, est élargi à toutes les personnes qui veulent
faire, ont l'intention de faire ou font quelque chose au niveau de
l'association OSM-France.
L'objectif de ce week-end est de faire connaissance, d'échanger et de
travailler collectivement autour du projet associatif OSM-FR. Nous en
profiterons pour faire un point plus général sur OSM.

Dans un premier temps, et afin d'organiser au mieux cette rencontre, nous
avons besoin :
- de savoir si nous pouvons compter sur votre présence ;
- que vous répondiez à ce questionnaire 
https://lite.framacalc.org/caphysiqueosm-fr
   (dates et heures d'arrivée
et de départ, hébergement) ;
- que vous veniez avec une spécialité locale à boire ou à manger afin de
partager le repas du samedi midi ;

Un temps convivial aura lieu le vendredi soir en fonction des heures
d'arrivée de chacun. Nous vous donnons rendez-vous dès 20h dans un lieu
restant à définir.

Afin de réserver dès maintenant et au plus vite vos billets de train, sachez
que le CAP aura lieu de samedi 15 février 9h au dimanche 16 février 16h.

Comme convenu, l'association prendra en charge les déplacements, les repas
du vendredi soir, samedi soir et dimanche midi. Nous cherchons également des
hébergements pour celles et ceux qui le souhaitent.
Concernant les modalités de prise en charge par l'association de votre
déplacement, veuillez contacter Donat (dona...@gmail.com ) ou Louis-Julien
(ljbou...@openstreetmap.fr ).
Nous vous recontacterons par la suite pour avoir vos avis et vos attentes et
pour vous donner le programme du week-end.

Attention, nous avons besoin de votre réponse urgemment et avant le dimanche
22 décembre 2019.

Bonne réception,

Tony EMERY



-
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

[Talk-GB] HS2 camden updates

2019-12-12 Diskussionsfäden Andy Robinson

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

Cheers
Andy


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

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

2019-12-12 Diskussionsfäden Tony Emery via Talk-fr

Je n'utilise pas quickOSM car les données sont déjà dans Postgresql via
osm2pgsql.

Mon problème est que si je demande à osm2pgsql d'extraire tous les champs
(via le fichier de config), je vais en avoir beaucoup dont la majorité sera
vide et cela rendra mes requêtes futures compliquées à gérer.

Du coup, j'ai fait quelques requêtes post intrégration dans postgresql pour
créer des tables thématiques (highway, landuse,...) à partir d'une table
dans laquelle se trouvent la clés principale et toutes les clés à extraire.
Sauf que ces clés doivent être déjà extraite par osm2pgsql et si je veux en
ajouter d'autres, c'est pas très souple.

J'avais pensé à mettre mon extracteur de hstore ( tags->'bridge' AS bridge )
dans la table mais les guillemets me font planter la requête.

Du coup, je me tourne vers qgis pour savoir si on peut faire des analyses
carto en utilisant directement le champ "tags" contenant le hstore dans la
sémiologie.



-
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-cz] JOSM a zobrazení stažených GPX dat

Tak je to potreba nove nastavit v preferencies - display - GPS points,
je tam toho vic.

Bye tom.k

čt 12. 12. 2019 v 11:54 odesílatel Tom Ka  napsal:
>
> Ano, body vidim taky. podle zmen v JOSM se s tim neco delalo, jestli
> je to feature nebo nejak rozdrbane ale tezko rict.
>
> Bye
>
> st 11. 12. 2019 v 19:02 odesílatel Pavel Pilát  napsal:
> >
> > Před pár dny jsem po měsíci spustil JOSM (aktualizoval se) a při stažení 
> > zájmové oblasti jsem zaškrtl i "RAW GPS data" jako obvykle, vrstva se 
> > vytvořila, ale v ní nic.
> >
> > Dnes už se zobrazují aspoň tečky, ale nepropojené.
> >
> > Pozorujete to taky?
> > ___
> > 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-cz] JOSM a zobrazení stažených GPX dat

Ano, body vidim taky. podle zmen v JOSM se s tim neco delalo, jestli
je to feature nebo nejak rozdrbane ale tezko rict.

Bye

st 11. 12. 2019 v 19:02 odesílatel Pavel Pilát  napsal:
>
> Před pár dny jsem po měsíci spustil JOSM (aktualizoval se) a při stažení 
> zájmové oblasti jsem zaškrtl i "RAW GPS data" jako obvykle, vrstva se 
> vytvořila, ale v ní nic.
>
> Dnes už se zobrazují aspoň tečky, ale nepropojené.
>
> Pozorujete to taky?
> ___
> 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] adresse mail rejetée

2019-12-12 Diskussionsfäden Alain Rpnpif


Le 10/12/2019 à 18:01, marc marc a écrit :

quelqu'un a un message d'erreur d'un de ces emails rejetté ?


Bonjour,

Je aais par une autre adresse que OVH est inscrit à tort comme spammeur chez 
spamhaus.

Ce qui explique que certains reçoivent des messages marqués [SPAM] et 
que d'autres ne les reçoivent pas car leur serveur est abonné à Spamhaus.


-- Rpnpif

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

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

2019-12-12 Diskussionsfäden Christine Karch

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-lt] CartoCon 2019 vaizdo medžiaga

2019-12-12 Diskussionsfäden Tomas Straupis

Sveiki

  OpenGIS jau papublikavo šių metų CartoCon pranešimų vaizdo medžiagą.
  https://www.youtube.com/watch?v=IMlJdCCQhZY

  ~4:10:00 prof. A.Bumblausko pranešimas „Žemaitija tarp kartografinių
klaidų“ - cepelinų dangaus nuotaikos praskaidrinimui. Iš karto po jo -
OpenStreetMap pranešimas.

  Kam įdomus QGIS:
  https://www.youtube.com/watch?v=aUTG6p0_WgM

-- 
Tomas

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

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

2019-12-12 Diskussionsfäden thevenon . julien

- 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

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

Am Do., 12. Dez. 2019 um 08:01 Uhr schrieb <
matthias.straetl...@buerotiger.de>:

> I want to use polygons (district boundaries) from OSM dataset to select
> points for a proprietary dataset.



>From a practical point of view, boundaries in OSM rarely originate from
surveys, you might be lucky to be able to identify the original source
(most likely open data) which may have a more liberal license than ODbL
(check the history and changeset source tags / object source tags).

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