Re: [OSM-talk-fr] Bien qu'étant abonné, je ne reçois pas tous les mails

[Francois Gouget]

On Sat, 20 Oct 2018, Gwenaël Jouvin wrote:

> Bonsoir,
> 
> J’ai le même problème et je remarque que nous sommes tous deux chez la Poste.
> 
> Je suppose que c’est dû à cet hébergeur. J’ai subi de gros problèmes 
> de réception de messages sur cette boîte il y a quelques mois, des 
> messages arrivaient 2, 3 jours après leur envoi…

Le filtre anti-spam de la poste a de gros problèmes. Les email manquants 
ne seraient-ils pas dans un dossier spam accessible uniquement sur le 
webmail de la poste?

D'après ce que j'ai pu glaner sur Internet malheureusement ce filtre 
anti-spam n'est pas désactivable. Mais on peut définir d'autres filtres 
qui ont la précédence. Le contournement consiste alors a définir un 
premier filtre qui dit que tous les email dont le sujet contient un 'a' 
doivent être envoyés directement dans la boite de réception ; puis un 
deuxième filtre qui dit la même chose pour tous ceux dont le sujet ne 
contient pas de 'a'.


-- 
Francois Gouget   http://fgouget.free.fr/
 Linux: the choice of a GNU generation___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-at] Neue Rechtschreibung von Wiener Straßennamen

[Robert Kaiser]

Stefan Nagy schrieb:

Das mit den Eigennamen ist meines Wissens eine Regel der neuen
Rechtschreibung. So wie ich das verstehe, hat die Gemeinde Wien mit dem
Gemeinderatsbeschluss vom 17. Dezember 1999 aber doch praktisch
beschlossen, die Eigennamen so abzuändern, dass sie den (allgemeinen)
Regeln der neuen Rechtschreibung entsprechen.


OK, Wien ist anders. Zur Kenntnis genommen.

KaiRo


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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

[Volker]

+1

+ drei Ergänzungen

1. Auch wenn die Antworten auf Changesetkommentare teilweise ziemlich 
patzig sind,  sollte generell der Ton in Changesetkommentaren, der 
tendenziell immer rauher wird, seitdem es die Changesetkommentare gibt, 
wieder in Richtung Sachargumente und Nettikette gehen.


2. Der Spass am "Rule lawering" sollte denjenigen, die es massiv 
parktizieren, gründlichst vergellt werden.


3. Ich bin keine Freund davon irgendjemanden wegen Kleinigkeiten bei der 
DWG zu verpetzen.



Am 20.10.2018 um 16:02 schrieb Frederik Ramm:

Hi,

On 10/19/2018 09:32 PM, Martin Koppenhoefer wrote:

kannst Du das spezifizieren? Wenn es ums Verkleben geht, soll man neue Mapper 
freundlich begrüßen und höchstens in einem Nebensatz das Verkleben ansprechen? 
Oder ist jeder Hinweis darauf verboten, wenn es um Neulinge geht?

Also, ich würde mal sagen, man soll es generell unterlassen, in einer
Changeset-Diskussion Zeugs zu diskutieren, das mit der konkreten
Änderung nichts zu tun hat.

Ansonsten würde ich sagen, das *absichtliche* Verkleben von Flächen und
Wegen, die man selbst nicht neu gemappt hat, sollte nach wie vor
kritisiert werden dürfen.

Aber wenn jemand neue Daten beiträgt und dabei ein bisschen "klebt", ist
das noch kein Grund für eine freundliche und erst recht nicht für eine
unfreundliche Ermahnung. Und wenn jemand dann trotzdem solche
Changeset-Kommentare schreibt, und ein Dritter das merkt, dann soll der
sich bitte an die DWG wenden statt auch noch in die Diskussion
einzusteigen und den Verteidiger der Entrechteten zu spielen.

Und wer in dieser Aussage eine Lücke findet und meint, er könnte immer
noch seine verklebe-politischen Ideen pushen, indem er z.B. die Mapper
per persönlicher Nachricht anschreibt oder ihnen gefaltete Zettelchen
unter die Windschutzscheibe klebt ("Du hast ja nur von
Changeset-Diskussionen gesprochen"), der kriegt dafür auch nicht den
Innovations-Award - einigen der Spezialisten in der aktuellen Diskussion
scheint das sog. "rule lawyering" ausgesprochenen Spass zu bereiten.

Mittelfristig wäre es gut, wenn wir in dieser Sache zu einem Konsens im
Projekt oder zumindest mal in Deutschland kommen könnten. So schwer kann
das doch nicht sein?

Bye
Frederik




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

Re: [OSM-talk-fr] Tag santé : wiki, osmose

[deuzeffe]

On 10/20/18 11:29 PM, marc marc wrote:

Le 20. 10. 18 à 23:05, deuzeffe a écrit :

D'abord, un labo. d'analyse.

-- healthcare=doctor
-- healthcare = laboratory


J'aurais mis le 2ieme (et corrigé l'osmecum vu qe le wiki dit déjà cela)


Effectivement, le healthcare=doctor pour les labos n'est pas mentionné 
dans le wiki. Normal, il est dans l'osmecum santé 
https://wiki.openstreetmap.org/w/images/f/f6/OSMecum-sant%C3%A9.pdf que 
j'ai aussi utilisé. My fault.



-- healthcare=yes
-- shop=optician


je ne considère pas un magasin comme un établissement de santé.
j'aurais viré healthcare


Snif.
--
deuzeffe - in TDL : corriger osmecum santé. (en ai-je vraiment le droit ?)

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

Re: [OSM-talk-fr] Tag santé : wiki, osmose

[marc marc]

Le 20. 10. 18 à 23:05, deuzeffe a écrit :
> > D'abord, un labo. d'analyse.
> -- healthcare=doctor
> -- healthcare = laboratory

J'aurais mis le 2ieme (et corrigé l'osmecum vu qe le wiki dit déjà cela)

> -- healthcare=yes
> -- shop=optician

je ne considère pas un magasin comme un établissement de santé.
j'aurais viré healthcare
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Lieux d'accueil enfants-parents

[deuzeffe]

Après discussion avec althio, que je remercie pour sa patience et ses 
conseils, j'ai opté pour :

- amenity=social_facility
- social_facility=outreach
- social_facitily:for=child;parent
- min_age=*
- max_age=6
- supervised=yes

--
oui, je laggue. Et donc ?

On 8/9/18 11:55 PM, deuzeffe wrote:

Bonsoir,

Les LAEP (ou parfois LAPE) sont des structures (~ 1500 ) officiellement 
reconnues et soutenues par la CAF (cf 
http://www.caf.fr/allocataires/vies-de-famille/futur-parent/garde-d-enfant/les-lieux-d-accueil-enfants-parents 
; il y a même une base en LO/OL),


C'est donc dans le thème enfance. Mais quel(s) tag(s) ? Ce ne sont pas 
des kinderkarten, même si ça peut s'en rapprocher. Quel tag pourrait-on 
utiliser voire créer ?


Merci pour vos réponses, quelles qu'elles soient.


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

Re: [OSM-talk-fr] Décalage cadastre

[deuzeffe]

Bonsoir,

Ça fait plaisir d'avoir une vision "d'un autre côté de la barrière". 
Merci pour votre partage d'expérience !


On 10/20/18 7:51 PM, Laurent Combe wrote:

Etant élu dans une mairie souffrant d'un tel problème "cadastre
significativement décalé" je me permet d'intervenir

je confirme :
prévenir la mairie ne sert pas à grand chose
la mairie le sait mais effectivement la mairie n'a pas la main

pour illustrer nous signalons chaque année des rectifications à faire à la
DGFiP pour corriger des informations ayant un effet sur le montant de
l'impôt. figurez-vous que ces informations peuvent ne pas être saisies par
les services fiscaux d'une année sur l'autre! Alors la rectification du
cadastre qui n'a qu'un aspect "esthetique" (j'exagere en disant cela, mais
je veux dire sans effet majeur sur le calcul de l'impôt) n'est vraiment pas
leur priorité.

Mais bonne nouvelle cette année nous avons été contacté pour nous dire que
la commune allait faire l'objet d'une refonte du cadastre. Cela devrait
améliorer la situation actuelle.Donc cela avance mais à leur rythme.

Laurent


Le mar. 16 oct. 2018 à 09:12, Christian Quest  a
écrit :


C'est sûrement un décalage des planches cadastrale... et comme Sébastien
l'indique il n'est pas homogène sur la comune, mais l'est souvent planche
par planche (donc sur un pâté de maison c'est en général homogène).

La mairie est sûrement au courant et impuissante car c'est à la DGFiP de
remettre ça au propre et comme cela n'a que peu d'impact sur usage, c'est
pas vraiment prioritaire.

Dans quelques décennies, lorsque la RCPU sera achevée, ça sera nickel ;)

--
Christian Quest - OpenStreetMap France
___
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] Osmose - École non intégrée

[deuzeffe]

On peut supposer que depuis que le MENESR a été séparé en 2, plus 
beaucoup d'info. ne circule entre les deux :(


Je vais contacter acce pour en avoir le cœur net.

On 10/19/18 9:21 AM, Christian Quest wrote:

J'ai rencontré il y a peu la personne qui s'occupe de maintenir la première
base (établissements du 1er et 2nd degré) et on n'a absolument pas parlé du
reste qui doit être hors de son périmètre.

Donc, le plus probable c'est que chaque base est gérée séparément, pas
différents services, et que le site que tu indiques à la fin agrège tout ça
pour permettre une recherche.


Le jeu. 18 oct. 2018 à 19:33, deuzeffe  a écrit :


On 10/18/18 9:56 AM, Christian Quest wrote:

Ces mentions sont normales (même si elles datent un peu) et

correspondent à

la Licence Ouverte, c'est donc tout à fait réutilisable pour OSM.


Merci pour la confirmation :)


Qu'est-ce qui est ventilé façon puzzle sur data.gouv ? Des liens seraient
utiles...


Les bases "enseignement" qu'osmose utilise pour l'OD. Par exemple :
- producteur MEN :
-- enseignement primaire (écoles maternelles et élémentaire), ici :

https://www.data.gouv.fr/fr/datasets/adresse-et-geolocalisation-des-etablissements-denseignement-du-premier-et-second-degres/
-- enseignement secondaire (collèges et lycées) : même base

Jusque là, tout va bien.

- producteur : ONISEP
-- Enseignement supérieur : "établissements" (entre quote parce qu'il y
manque les établissements au sens administratif du terme, voir le
descriptif du jeu de données) :

https://www.data.gouv.fr/fr/datasets/etablissements-denseignement-superieur-2
()

Ce que n'utilise pas osmose :
- source MESRI
-- les rectorats :

https://www.data.gouv.fr/fr/datasets/les-rectorats-dacademies-et-vice-rectorats/

-- les BU (2 jeux) :

https://www.data.gouv.fr/fr/datasets/bibliotheques-de-lenseignement-superieur/
et

https://www.data.gouv.fr/fr/datasets/services-de-documentation-et-sieges-des-bibliotheques-de-lenseignement-superieur/
-- les implantations des établissement publics d'ens. sup. avec les UFR
(entre autres) :

https://www.data.gouv.fr/fr/datasets/implantations-des-etablissements-denseignement-superieur-publics/
-- les principaux établissements d'ens. sup. :

https://www.data.gouv.fr/fr/datasets/principaux-etablissements-denseignement-superieur/

Et plein d'autres bases que je n'ai pas eu le temps de chercher.

Cependant, une rapide recherche sur acce
(http://www.education.gouv.fr/acce_public/index.php ) montre que tout ça
y est déjà plus plein d'autres services/établissements/UA du domaine
éducation. Soit il n'y a qu'une seule base, soit une métabase, soit...

Bref, dommage qu'on ne puisse pas intégrer (intégrer, j'ai dit !) plus
de choses plus finement par manque d'interopérabilité (?). Même s'il
faut de la découpe pour les fines analyses réalisées par osmose.

--
deuzeffe, archiviste ou bibliothécaire, suivant les heures.

___
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

[OSM-talk-fr] Tag santé : wiki, osmose

[deuzeffe]

et Nunuche.

Hello,

Avec la mise à jour de l'analyse des établissements de santé par osmose, 
plusieurs erreurs sont remontées sur des POI que je pensais avoir 
correctement taggués.


Soit j'ai fait des bêtises (hypothèse hautement probable) soit c'est 
autre chose.


J'ai tenté de suivre les instruction du wiki, ici : 
https://wiki.openstreetmap.org/wiki/FR:Comment_cartographier_un_(sant%C3%A9)#Professions_param.C3.A9dicales


D'abord, un labo. d'analyse.
- le wiki dit :
-- health_facility:type=laboratory
-- healthcare=doctor
-- healthcare:speciality=biolog
- Osmose ne le trouve pas et propose de le créer avec :
-- healthcare = laboratory
-- healthcare:speciality = biology

Soit le wiki n'est pas à jour, soit l'analyse d'osmose est à affiner soit...

Ensuite des opticiens ou des magasins d'appareils auditifs :
- selon le wiki, j'ai taggué :
-- healthcare=yes
-- shop=optician ou hearing_aids
- osmose proteste :
- Établissements de soins autres que les hopitaux without (valid) 
ref:FR:FINESS


Est-ce le tag healthcare=yes qui pose problème ?

Soit le wiki n'est pas assez explicite et je l'ai trop interprété, soit 
il faut affiner l'analyse d'osmose.


--
deuzeffe, qui a découvert d'autres soucis de FINESS invalide/absent sur 
des amenity=social_facility


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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

[sepp1974]

...Straßen sind da nur ein Beispiel ;-)

Darum gehts doch offenbar nicht. Woruauf soll ich mich denn als Mapper 
beziehen? Auf ein stellenweise wenig bis gar nicht aussagekräftiges 
Wiki, auf Meinung A, B oder C aus einem Forum, möglichst noch auf 
stellenweise uralte Forenbeiträge von 18-Hundertfrühling oder kann ich's 
selbst entscheiden, nachdem ich zumindest die Möglichkeit hatte, mir 
Vor- und Nachteile der jeweiligen Variante mal zu Gemüte zu führen um es 
auch zu verstehen, warum, weshalb, wieso?


Und solange solbst innerhalb von OSM dort kein Konsens besteht, wäre das 
doch ersteinmal DIE Lösung oder gehts nicht um eine solche, sondern nur 
wieder darum, wer schlussendlich "Recht" bekommt?


Ohne jetzt hier ne Diskussion anzufachen - es geht doch schlussendlich 
darum, die Realität abzubilden und in dieser gibt es KEINE leeren 
Flächen und daraus ergibt sich zwangsläufig das Verkleben dieser jenigen 
welchen. Ob es nun Sinn macht, Straßenbelag als Fläche zu mappen, sei 
mal dahin gestellt. Der Kompromiss könnte bspw. in einer 
einvernehmlichen Festlegung oder besser Empfehlung bestehen, angrenzende 
Flächen nicht zu verkleben, solange Straßenbelagfläche nicht gemappt 
wurde, usw. usf. <= nur muss sowas irgendwo nachlesbar sein und zwar 
nicht in einem Forenbeitrag von 2009 auf Seite 24, vorletzter 
Seiteneintrag nach Bemühen einer Suchfunktion. Es scheitert doch beim 
Neuuser schon meist an der richtigen Begrifflichkeit, um eine Suche auch 
effektiv auszuführen. Mal ganz abgesehen davon, mappt der Neuuser 
wahrscheinlich erstmal direkt im Browser, klickt auf's Wiki und erfährt 
u.U. nicht viel bis gar nix. Der sucht nicht nach irgendeinem Forum und 
dort auch noch nach einem bestimmten Thema oder fragt in einer 
Telegrammgruppe oder wartet, bis der nächste stammtisch in seiner Stadt 
stattfindet.


Grüße
Sepp



Am 20.10.2018 19:11 schrieb Martin Koppenhoefer:

sent from a phone


On 20. Oct 2018, at 18:23, sepp1...@posteo.de wrote:

In der Realität gibt es nunmal keine "leeren Flächen",



in OSM gibt es aber leere Flächen: wo bisher noch nicht gemappt wurde.
Wenn in Deutschland leere Flächen neben der Straße stören dann liegt
es vermutlich daran, dass die Straße noch nicht als Fläche gemappt ist
;-)



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


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

[Talk-GB] OSM on Met Office

[Martin Wynne]

The Met Office has a new web site in beta. The mapping is now credited 
to OSM:


 https://beta.metoffice.gov.uk/weather/forecast/gcmg86my9#?date=2018-10-20

Martin.

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

Re: [Talk-at] Neue Rechtschreibung von Wiener Straßennamen

[Stefan Nagy]

Am Samstag, den 20.10.2018, 13:56 +0200 schrieb Robert Kaiser:
> Andreas Geyer-Schulz schrieb:
> > Leider habe ich zu diesem Thema im Forum oder in der Mailingsliste
> > keine klärende Diskussion gefunden. (Ein wenig steht bei diesem
> > Kartenkommentar [4].) Es gibt einige Straßen, die davon betroffen
> > sind.
> 
> Die Rechtschreibregeln (insbesondere Dinge wie die Verwendung von
> "ß") gelten explizit nicht für Eigennamen. Es gilt die Schreibung vor
> Ort. Also, was am Straßenschild steht - und hoffentlich steht das
> selbe auf der Wiener Mehrzweckkarte (die hier sicher höhere Priorität
> hat als das BEV).

Das mit den Eigennamen ist meines Wissens eine Regel der neuen 
Rechtschreibung. So wie ich das verstehe, hat die Gemeinde Wien mit dem
Gemeinderatsbeschluss vom 17. Dezember 1999 aber doch praktisch
beschlossen, die Eigennamen so abzuändern, dass sie den (allgemeinen)
Regeln der neuen Rechtschreibung entsprechen.

Zitat: "In Abänderung des Gemeinderatsbeschlusses vom 30. Jänner 1981
werden für die Schreibung von Verkehrsflächenbezeichnungen und
geografischen Namen die Grundsätze der Wiener Nomenklaturkommission
dahingehend ergänzt, dass grundsätzlich die Neue Rechtschreibung
Anwendung findet. Auf Straßentafeln, Orientierungsnummerntafeln und
dergleichen sowie in Personaldokumenten ist die geänderte Schreibweise
nur bei Neuanbringung beziehungsweise Neuausstellung zu
berücksichtigen". [1]

Lieg ich damit falsch? Und wenn ja: Wie ist der Gemeinderatsbeschluss
dann zu verstehen?

Stefan



[1] https://www.wien.gv.at/kultur/archiv/nomenklaturkommission.html

-- 
E-Mails signieren & verschlüsseln · https://emailselfdefense.fsf.org/de/


signature.asc
Description: This is a digitally signed message part
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [OSM-talk-fr] Relation de riviere, Le Rhone

[marc marc]

Le 18. 10. 18 à 23:55, François Lacombe a écrit :
> La 1ere pour sur le filaire river : 
> https://www.openstreetmap.org/way/34907146

c'est globalement correct https://www.openstreetmap.org/relation/1075117
même s'il y a de nombreux soucis sur la relation dont des zones
sans rôle mainstream et à l'inverse des zones avec plusieurs mainstream 
au même endroit.
J'ai corrigé une partie du tracé hier mais pas encore touché
à la relation pour éviter d'être à plusieurs dessus.

> La 2nd sur le riverbank, un multipolygon sur tout le court du fleuve : 
> https://www.openstreetmap.org/relation/660056

en plus d'être déconseillé par le wiki et inutile
c'est incorrect :
- un ensemble de polygone qui se touche ne forment un multipolygone.
un multipolygone dans osm est un ou plusieurs polygones qui ne se touche 
pas.
Le rendu osm.org avait même parlé d’arrêté de faire de la devinette
et de ne plus faire aucun rendu de certains multipolygone erronés
afin que l'erreur soie visible au lieu d'avoir des problèmes en cascade.
- Les berges du Rhône ne s'appelle pas le Rhône, il y a confusion.

> Ne faudrait-il pas mettre le wikidata sur la 1ere relation et supprimer 
> la 2nde pour ne laisser que des polygones riverbanks continus sans 
> relation ?

oui

la page sur le wiki fr mériterait aussi d'être rafraîchie/rapprochée
avec le contenu de la version anglaise.

Et tant qu'à dire, les rôles tributary conflictuels
sont sur la mauvaise relation
https://wiki.openstreetmap.org/wiki/Relation:watershed

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

Re: [OSM-talk-fr] Décalage cadastre

[Laurent Combe]

Etant élu dans une mairie souffrant d'un tel problème "cadastre
significativement décalé" je me permet d'intervenir

je confirme :
prévenir la mairie ne sert pas à grand chose
la mairie le sait mais effectivement la mairie n'a pas la main

pour illustrer nous signalons chaque année des rectifications à faire à la
DGFiP pour corriger des informations ayant un effet sur le montant de
l'impôt. figurez-vous que ces informations peuvent ne pas être saisies par
les services fiscaux d'une année sur l'autre! Alors la rectification du
cadastre qui n'a qu'un aspect "esthetique" (j'exagere en disant cela, mais
je veux dire sans effet majeur sur le calcul de l'impôt) n'est vraiment pas
leur priorité.

Mais bonne nouvelle cette année nous avons été contacté pour nous dire que
la commune allait faire l'objet d'une refonte du cadastre. Cela devrait
améliorer la situation actuelle.Donc cela avance mais à leur rythme.

Laurent


Le mar. 16 oct. 2018 à 09:12, Christian Quest  a
écrit :

> C'est sûrement un décalage des planches cadastrale... et comme Sébastien
> l'indique il n'est pas homogène sur la comune, mais l'est souvent planche
> par planche (donc sur un pâté de maison c'est en général homogène).
>
> La mairie est sûrement au courant et impuissante car c'est à la DGFiP de
> remettre ça au propre et comme cela n'a que peu d'impact sur usage, c'est
> pas vraiment prioritaire.
>
> Dans quelques décennies, lorsque la RCPU sera achevée, ça sera nickel ;)
>
> --
> Christian Quest - OpenStreetMap France
> ___
> 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-es] Qué poner en source cuando la fuente es una guía, catálogo o hemeroteca...

[dcapillae]

Hola.

Me parece buena estrategia. La ubicación de las obras de arte público, así
como sus eventuales nombres y seguramente sus autores, suelen ser de domino
público. Si esa información se obtiene de fuentes válidas (autorizadas
expresamente o compatibles con la licencia ODbL), del conocimiento local o
por trabajo de campo propio (de un panel informativo en la calle, por
ejemplo), no hay problema. Ahora bien, si esa misma información se obtiene
de una fuente protegida por derechos de autor, la información podrá seguir
siendo de dominio público, pero la fuente no nos sirve y no se puede citar
como tal en OSM. Habría que obtener esa misma información a partir de otras
fuentes, por otros medios, o pedir permiso.

Una página web cuyo contenido esté protegido por derechos de autor no sirve
como fuente en OSM, ni siquiera si todo su contenido está disponible en
dominio público a partir de otras fuentes. El dominio público permite
reutilizar la información en obras derivadas bajo condiciones de licencia
restrictivas, y en ese caso hay que respetar las nuevas condiciones de
licencia. Si queremos usar la página web como fuente y el autor la tiene
publicada bajo condición de «todos los derechos reservados», tendremos que
pedirle permiso.



-
Daniel Capilla 
OSM user: dcapillae 
--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

[Martin Koppenhoefer]

sent from a phone

> On 20. Oct 2018, at 18:23, sepp1...@posteo.de wrote:
> 
> In der Realität gibt es nunmal keine "leeren Flächen",


in OSM gibt es aber leere Flächen: wo bisher noch nicht gemappt wurde. Wenn in 
Deutschland leere Flächen neben der Straße stören dann liegt es vermutlich 
daran, dass die Straße noch nicht als Fläche gemappt ist 
;-)



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

Re: [Talk-it] [Alberi monumenmtali] Quale licenza?

[Cascafico Giovanni]

Il giorno ven 19 ott 2018 alle ore 15:36 Andrea Musuruane <
musur...@gmail.com> ha scritto:

> Non mi sembra corretto usare il tag name per indicare il nome volgare
dell'albero.
+1
mappare nome volgare come genus:it?

> Inoltre, l'uso del tag source sui dati è deprecato. Meglio usare solo
quello sul changeset, magari fornendo anche altre info.

Forse mi è sfuggito qualcosa: dove leggi che va sui dati? Ho aggiuto i
suggerimenti per i tag del changeset


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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

[sepp1974]

Hi @ll,

grundsätzlich wäre es wünschenswert, wenn das Wiki für derartige 
Grundsatzfragen einfach aussagekräftig wäre. Vor- und Nachteile, Sinn 
und Unsinn und zwar ganz neutral. Der Neueinsteiger mappt in aller Regel 
für die Kartenansicht und -darstellung und steigt so ein.


In der Realität gibt es nunmal keine "leeren Flächen", selbst wenn das 
Lösen der verklebten Punkte im Nachgang nervig ist - das parallele 
Mappen zu bestehenden Flächen ist genau so nervig, vor allem in der 
In-Browser-Variante...


Gruß Sepp



Am 20.10.2018 16:02 schrieb Frederik Ramm:

Hi,

On 10/19/2018 09:32 PM, Martin Koppenhoefer wrote:
kannst Du das spezifizieren? Wenn es ums Verkleben geht, soll man neue 
Mapper freundlich begrüßen und höchstens in einem Nebensatz das 
Verkleben ansprechen? Oder ist jeder Hinweis darauf verboten, wenn es 
um Neulinge geht?


Also, ich würde mal sagen, man soll es generell unterlassen, in einer
Changeset-Diskussion Zeugs zu diskutieren, das mit der konkreten
Änderung nichts zu tun hat.

Ansonsten würde ich sagen, das *absichtliche* Verkleben von Flächen und
Wegen, die man selbst nicht neu gemappt hat, sollte nach wie vor
kritisiert werden dürfen.

Aber wenn jemand neue Daten beiträgt und dabei ein bisschen "klebt", 
ist

das noch kein Grund für eine freundliche und erst recht nicht für eine
unfreundliche Ermahnung. Und wenn jemand dann trotzdem solche
Changeset-Kommentare schreibt, und ein Dritter das merkt, dann soll der
sich bitte an die DWG wenden statt auch noch in die Diskussion
einzusteigen und den Verteidiger der Entrechteten zu spielen.

Und wer in dieser Aussage eine Lücke findet und meint, er könnte immer
noch seine verklebe-politischen Ideen pushen, indem er z.B. die Mapper
per persönlicher Nachricht anschreibt oder ihnen gefaltete Zettelchen
unter die Windschutzscheibe klebt ("Du hast ja nur von
Changeset-Diskussionen gesprochen"), der kriegt dafür auch nicht den
Innovations-Award - einigen der Spezialisten in der aktuellen 
Diskussion

scheint das sog. "rule lawyering" ausgesprochenen Spass zu bereiten.

Mittelfristig wäre es gut, wenn wir in dieser Sache zu einem Konsens im
Projekt oder zumindest mal in Deutschland kommen könnten. So schwer 
kann

das doch nicht sein?

Bye
Frederik


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

Re: [Talk-ca] Import des arrêts d'autobus de l'ARTM

[marc marc]

Bonjour,

c'est exact. une licence "non commercial uniquement" n'est
pas compatible avec osm, vu qu'on doit pouvoir utiliser
les données osm aussi dans un cadre commercial.
il faut demander une autorisation spécifique "droit d'utiliser
les données en vue de contrinuer à osm"
de nombreuses sources l'ont accordé mais c'est loin d'être automatique.

Courage :)

Cordialement,
Marc

Le 19. 10. 18 à 22:28, Pierre Béland a écrit :
> Bonjour Claude,
> 
> Je connais peu les relations pour itinéraires de services de transport.
> 
> Le groupe de discussion Import de OSM suit de très près tout import. Et 
> la question de licence c'est toujours très litigieux. Si pas indiqué 
> OdBL, il faut habituellement une autorisation écrite permettant 
> spécifiquement à OSM d'utiliser les données.
> 
> Licences ; À première vue RTL Longueuil et STL Laval ont la même licence 
> avec un libellé indiquant que pas pour fin commerciales
> -> Automatiquement, cela est non conforme à OdBL et donc il faudrait une 
> autorisation écrite
> 
> 
> Pierre
> 
> 
> Le vendredi 19 octobre 2018 13 h 55 min 35 s HAE, Alouette955 
>  a écrit :
> 
> 
> Bonjour,
> Il y a quelques temps je lançais une consultation sur ma proposition 
> d’import pour les arrêts d’autobus du Réseau de transport Métropolitain, 
> maintenant EXO. J’attends incessamment leur autorisation pour l’import 
> avec mention sur la page des contributeurs.
> https://wiki.openstreetmap.org/wiki/FR-Import_arr%C3%AAts_d%27autobus,_EXO_r%C3%A9seau_de_transport_m%C3%A9tropolitain
> Tout commentaire sur ma méthodologie est bienvenue.
> Depuis j’ai compris que EXO, tout comme la STM (Montréal), la STL 
> (Laval) et le RTL (Longueuil) sont des opérateurs distincts mais qui 
> collaborent sous l’égide de l’ARTM. Un peu compliqué mais maintenant 
> clarifié. J’en ai profité pour créer une page pour l’ARTM dans le wiki:
> https://wiki.openstreetmap.org/wiki/FR-ARTM_-_Autorit%C3%A9_r%C3%A9gionale_de_transport_m%C3%A9tropolitain
> La STL et le RTM ont une licence qui me semble beaucoup plus permissive:
> http://www.rtl-longueuil.qc.ca/fr-CA/donnees-ouvertes/
> https://www.stl.laval.qc.ca/fr/stl-synchro/developpeurs/ (voir à 
> l’encadré Conditions d’utilisation)
> Je songe donc les inclure à mon projet d’import sans autre formalité 
> autre de les indiquer dans la page des contributeurs.
> La question est: Aie-je bien compris ces licences?
> Il ne me semble pas que l’import dans la base de données OSM est une 
> utilisation commerciale ou quasi commerciale mais peut-être y a-t-il un 
> précédent qui m’obligerait à obtenir une autorisation spécifique.
> Merci,
> Claude
> ___
> 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: [OSM-talk-fr] Bien qu'étant abonné, je ne reçois pas tous les mails

[marc marc]

Le 20. 10. 18 à 15:31, Paul Desgranges a écrit :
> je ne reçois qu'un mail sur cinq à peu près

ouvre un ticket chez la poste :)
mais vu que c'est une produit gratuit...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Contributeur(e) compulsif(ve) et imprécis, faut faire quoi ?

[marc marc]

Bonjour,

Le 20. 10. 18 à 14:28, ades a écrit :
> Que fait-on quand on découvre qu’un nouveau contributeur (depuis le 23 
> septembre, 289 changesets) fait n’importe quoi ou presque.

il y a bcp de point différent dans ton email.
d'une manière générale, avec un nouveau, on peux partir du principe que 
c'est souvent involontaire et qu'il va falloir l'aider à progresser.
mettre un commentaire sur le changeset aide souvent pour quand "trop 
c'est trop". ca permet aussi de le suivre à plusieurs.

> pas de source sur l’objet

ca j'espère :) depuis le temps qu'on peux structurer l'info
sur le changeset :)

> "Corrections" des bâtiment du cadastre  (mis à jour à partir du fichier 
> etalab de juin 2018) à partir de la BDOrtho, mais là ça frole le vendalisme 
> ;-) .

je ne serrais pas si sévère. un débutant n'a pas de moyen de deviner 
qu'il y a une source cadastre plus fiable.
c'est le genre de chose qu'on devrait mettre dans l'acceuil aux nouveaux
pour lequel un coup de main n'est pas refusé :)

> Le cadastre est, certes, décalé  par rapport à l’ortho, (3px soit 60cm

un solution c'est d'alligner le cadastre et sauver/partager le décalage 
local... à voir si c'est déjà activé sur iD. Sur Josm oui.

> il faudrait  vérifier systématiquement toutes ces contributions

dans ma zone de confort je vérifie tout :)

> certaines sont intéressantes

espérons que les autres problèmes se résolvent dans ce cas.
sinon faudra demander au DWG de faire un message un peu plus 
"officiel"... et espérer là aussi que cela suffise.

> tout reprendre dès maintenant en laissant un commentaire ?

si t'as la motivation et le temps, c'est sûrement le mieux.
sinon cibler le plus "grave"

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

Re: [OSM-talk-fr] Bien qu'étant abonné, je ne reçois pas tous les mails

[Gwenaël Jouvin]

Bonsoir,

J’ai le même problème et je remarque que nous sommes tous deux chez la Poste.

Je suppose que c’est dû à cet hébergeur. J’ai subi de gros problèmes de 
réception de messages sur cette boîte il y a quelques mois, des messages 
arrivaient 2, 3 jours après leur envoi…
Les soucis se sont calmés mais reviennent çà et là.
Faudrait vraiment que tout le monde envoie ses mails avec un timbre rouge :-)

Ma parade : inscrit avec une autre adresse pour tout avoir ou consulter les 
archives.

Gwenaël


Le 20/10/2018 à 15:31, Paul Desgranges a écrit :
> Bonjour
>  Bien qu'étant abonné a talk-fr@openstreetmap.org, je ne reçois qu'un mail 
> sur cinq à peu près, j'ai vérifié la gestion des indésirable bien sûr sans y 
> trouver d'explication. Ça m'oblige à aller consulter sur les archives de osm 
> talk fr 
>  
> pour avoir les fils de discussions complets, puis de copier-coller à la main 
> les messages pris dans les archives dans un des messages qui est arrivé dans 
> ma mailbox pour faire une réponse en citant l'émetteur. Ça entre-melle les 
> réponses que je peux faire pas au bon endroit dans le fil de discussion, 
> c'est un peu embêtant tout ça. Je ne sais pas si je suis le seul dans ce cas, 
> et/ou si qqun aurait une explication?   
> Merci
> Paul
> 
> 
> 
> ___
> 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-de] Androhung von Benutzersperren für Verklebe-Ideologie

[Frederik Ramm]

Hi,

On 10/19/2018 09:32 PM, Martin Koppenhoefer wrote:
> kannst Du das spezifizieren? Wenn es ums Verkleben geht, soll man neue Mapper 
> freundlich begrüßen und höchstens in einem Nebensatz das Verkleben 
> ansprechen? Oder ist jeder Hinweis darauf verboten, wenn es um Neulinge geht?

Also, ich würde mal sagen, man soll es generell unterlassen, in einer
Changeset-Diskussion Zeugs zu diskutieren, das mit der konkreten
Änderung nichts zu tun hat.

Ansonsten würde ich sagen, das *absichtliche* Verkleben von Flächen und
Wegen, die man selbst nicht neu gemappt hat, sollte nach wie vor
kritisiert werden dürfen.

Aber wenn jemand neue Daten beiträgt und dabei ein bisschen "klebt", ist
das noch kein Grund für eine freundliche und erst recht nicht für eine
unfreundliche Ermahnung. Und wenn jemand dann trotzdem solche
Changeset-Kommentare schreibt, und ein Dritter das merkt, dann soll der
sich bitte an die DWG wenden statt auch noch in die Diskussion
einzusteigen und den Verteidiger der Entrechteten zu spielen.

Und wer in dieser Aussage eine Lücke findet und meint, er könnte immer
noch seine verklebe-politischen Ideen pushen, indem er z.B. die Mapper
per persönlicher Nachricht anschreibt oder ihnen gefaltete Zettelchen
unter die Windschutzscheibe klebt ("Du hast ja nur von
Changeset-Diskussionen gesprochen"), der kriegt dafür auch nicht den
Innovations-Award - einigen der Spezialisten in der aktuellen Diskussion
scheint das sog. "rule lawyering" ausgesprochenen Spass zu bereiten.

Mittelfristig wäre es gut, wenn wir in dieser Sache zu einem Konsens im
Projekt oder zumindest mal in Deutschland kommen könnten. So schwer kann
das doch nicht sein?

Bye
Frederik

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

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

[OSM-talk-fr] Bien qu'étant abonné, je ne reçois pas tous les mails

[Paul Desgranges]

Bonjour
 Bien qu'étant abonné a talk-fr@openstreetmap.org, je ne reçois qu'un 
mail sur cinq à peu près, j'ai vérifié la gestion des indésirable bien 
sûr sans y trouver d'explication. Ça m'oblige à aller consulter sur les 
archives de osm talk fr 
 
pour avoir les fils de discussions complets, puis de copier-coller à la 
main les messages pris dans les archives dans un des messages qui est 
arrivé dans ma mailbox pour faire une réponse en citant l'émetteur. Ça 
entre-melle les réponses que je peux faire pas au bon endroit dans le 
fil de discussion, c'est un peu embêtant tout ça. Je ne sais pas si je 
suis le seul dans ce cas, et/ou si qqun aurait une explication?

Merci
Paul


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

Re: [OSM-talk-fr] Piscine municipale vs piscine privée

[Paul Desgranges]

Le 20/10/2018 à , marc marc a écrit :


/- 71 qui ont déjà un tag leisure />>/on n'a pas du tout les mêmes résultats 
/>>/62 amenity=swimming_pool and leisure=* /

62 ou 71 sur 7000 c'est franchement la même chose :)
osm n'est pas statique, le fait que qlq cas ont été corrigé à la main
en 12h ne change rien fondamentalement.


OUI, mais c'est ce que je disais moi-même n'est-ce pas "à quelques unités près 
comme c'est pas exactement
au même moment, ça serait une explication mais là c'est un peu plus que ça"
Parce que effectivement tu ne parles pas des autres quantités (il y en avait 4 
ou 5) qui étaient assez différentes,
et je suis désolé, si déjà on est pas d'accord sur la façon de compter et si on 
arrive
pas aux mêmes résultats sans que cela soit explicable, ça devient un peu 
compliqué de discuter du reste ...
J'ai donné en même temps que les quantités auxquelles j'arrive, la façon avec 
laquelle j'y suis arrivé,
et toi comme avais-tu compté ? On ne le saura pas ?

et si tu fais la stat ce soir, il n'en restera plus, parce qu'au lieu
de compter par 3 fois le nombre exact, je vais les corriger,
c'est plus efficace :)



/cela fait environ 7000 à modifier en leisure=swimming_pool. />>/2- J'enlèverais />>/nommés 
/>>/traiter individuellement) />>/building />>/leisure=sports_centre />>/leisure=* /

C'est cela (+ la taille) qui a été retiré pour arriver à 7000.

Ça j'ai bien compris, j'ai pas contesté cette soustraction, et c'est pour ça 
que j'ai dit qu'on était globalement d'accord :-)
Il y avait pas mal d'autres points dans le mail précédent qui restent sans 
réponse, c'est dommage cette façon de tronquer
le mail de l'émetteur pour ne répondre qu'à une petite partie.



maintenant si tu préfères corriger tous ces cas à la main
avant de toucher aux 7000, pourquoi pas.

Pourquoi pas ? dans ce cas on est d'accord
Je propose, oui, de traiter tous ces cas spéciaux avant de faire la grosse 
modif.
Pas forcément à la main, puisque il y a des qq règles pour progressivement 
enlever
les cas litigieux faciles... Si tu es d'accord avec ça, c'est l'essentiel.
Et puis après, il aurait fallu enlever effectivement les cas "area>"
Et puis après, et avant de toucher aux 7000 qui restent, il faudra aviser à 
nouveau
avant de massivement faire une transformation qui sinon risquerait
de transformer en simple "bassin" des cas de piscines publiques ?

J'explique simplement la méthode et l'ordre dans lequel il faudrait le faire 
pour y arriver :-)

A plus
Paul


 




Le 20/10/2018 à 12:04, Paul Desgranges a écrit :

Le 19/10/2018 à 10:35, Noémie Lehuby a écrit :


Salut Paul,
On est quasiment d'accord !
Mon plan était de commencer par la proposition de Marc de transformer 
toutes les amenity=swimming_pool en leisure=swimming_pool comme 
première étape.
Puis de faire ce que tu décris, mais sur les leisure=swimming_pool, 
puisque comme tu l'as indiqué, il y a aussi des leisure=swimming_pool 
qui devraient être leisure=sports_centre.


Noémie


Bon et bien on est presque d'accord globalement  :-)
J'essaye de bien comprendre jusqu'au bout cette histoire ... tout 
n'est pas encore clair sur ce qu'on veut faire et dans quel ordre

> marc marc a écrit :
> résumé de la modif automatique proposée en France
> en tenant compte de tous les suggestions :
>7371 amenity=swimming_pool
>- 71 qui ont déjà un tag leisure
Par exemple déjà on n'a pas du tout les mêmes résultats (à quelques 
unités près comme c'est pas exactement au même moment, ça serait une 
explication mais là c'est un peu plus que ça)
62 amenity=swimming_pool and leisure=* in France 
https://overpass-turbo.eu/s/CWm
6 amenity=swimming_pool and leisure=sports_centre in France 
https://overpass-turbo.eu/s/CWe

  >- 272 avec un tag name
161 amenity=swimming_pool and name=* https://overpass-turbo.eu/s/CUk
15 amenity=swimming_pool and name=Piscine https://overpass-turbo.eu/s/CWo
3 amenity=swimming_pool and name="Piscine privée" 
https://overpass-turbo.eu/s/CWp

0 amenity=swimming_pool and name="piscine privée"
>- 39 avec un tag building
113 amenity=swimming_pool and building=yes in France 
https://overpass-turbo.eu/s/CUI 
121 amenity=swimming_pool and building=* in France 
https://overpass-turbo.eu/s/CWx


>- 18 avec une surface dams josm areasize > 2000m2
>cela fait environ 7000 à modifier en leisure=swimming_pool.
>pas d'objection ?


>Pour le reste, je m’abstiens de le faire en automatique,
>mais je donne volontiers un coup de main pour le faire
>à la main, en regardant chaque objet.
>>Le 19. 10. 18 à 08:42, Paul Desgranges a écrit :
>>/    les "amenity=swimming_pool + name=*" /
>>/ en "leisure=sports_centre + /
>>/sport=swimming"
/>Je doute que tu puisses tirer une conclusion aussi binaire de
>la présence d'un nom, j'ai déjà croisé souvent des name=piscine privée

Il y a effectivement 3 name="Piscine privée" et 0 name="piscine 
privée", 

[OSM-talk-fr] Contributeur(e) compulsif(ve) et imprécis, faut faire quoi ?

[ades]

Bonjour,

Que fait-on quand on découvre qu’un nouveau contributeur (depuis le 23 
septembre, 289 changesets) fait n’importe quoi ou presque. Beaucoup à la 
Ménitré (insee 49201) et alentour, mais aussi en centre ville à Angers.

Tentatives (éparpillées et géométriquement fausses) de micro mapping en 
agglomération, maladie du ‘name=*', quitte à inventer le nom ou à y mettre 
quelque chose qui relève plutôt de ‘description=*’. Mélange des tags 
‘landuse=*' et 'natural=*' pour des objets de même nature, pas de source sur 
l’objet, etc., etc.

"Corrections" des bâtiment du cadastre  (mis à jour à partir du fichier etalab 
de juin 2018) à partir de la BDOrtho, mais là ça frole le vendalisme ;-) . 

Le cadastre est, certes, décalé  par rapport à l’ortho, (3px soit 60cm ±5cm 
mesurés par rapport à un point de nivellement) mais de là à modifier certains 
bâtiments, en dessinant la paralaxe des corniches plutôt que la trace au sol… 
mais pas ls autres (y-en a que 2034)…

Pour être un peu rigoureux dans la production d'OSM, il faudrait  vérifier 
systématiquement toutes ces contributions. Mais ça pourrait vexer ;-).

Il y a eut ébauche de dialogue (échange de mails, rdv transformé en lapin) mais 
ces échanges portant sur des objets particuliers pris à titre d’exemple n’ont 
servis à rien, ça continue. Et j'ai pourtant bien indiqué, le wiki, le talk et 
le forum. Et même en renvoyant sur le wiki pour une erreur, celle ci est 
reproduite ailleurs, plus tard.

Bémol, toutes les contrib ne sont pas fausses ou idiotes, certaines sont 
intéressantes, sauf qu’elles sont très mal faites (je suis gentil).

Bref, faut faire quoi ? attendre que le contributeur compulsif se calme et 
reprendre  plus tard (vérifier et le cas échéant modifier) ? tout reprendre dès 
maintenant en laissant un commentaire ? rien faire et laisser tomber ?


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

Re: [Talk-es] Qué poner en source cuando la fuente es una guía, catálogo o hemeroteca...

[Lanxana .]

Buenos días,

en este momento tengo dos proyectos en mente, que son los que requieren el
uso de las fuentes de datos sobre las que preguntaba:

1 - Proyecto "artwork", sobre el que saldrán más dudas, que ya iré
consultando. Quiero ubicar las diferentes obras de arte urbano que hay por
mi zona, conseguí una guía que editó la Diputación de Girona sobre las
esculturas en vía pública [1] y [2]. En este caso, uso las indicaciones que
dan sobre su ubicación para verificar que esté, ir y fotografiarla. En
algunos casos el nombre, autor y/o fecha aparecen indicados en una placa
junto a la propia obra, pero en esculturas en medio de una rotonda en vía
rápida, veo difícil cruzar hasta la rotonda para buscar la placa, caso que
estuviera. En otros, sabiendo el autor o la fecha (gracias a la guía),
puedo buscar en internet al autor o noticias de la época para confirmar
estos datos. En ambos casos creo que podría usar source=survey, pues los
datos se obtienen tras trabajo de campo propio. Aunque me queda la duda de,
si el autor tiene página web propia con un listado de sus obras, ¿puedo
usar esa información o tengo que pedir autorización expresa al artista para
usarla?
2 - Para recoger la historia del nombre de una calle, en el caso de Girona
había pensado en una primera fase usar los artículos que se publicaron en
el periódico "El Punt" [3]. También tengo noticia de que el propio
ayuntamiento editó una guía sobre las calles de la ciudad, en cuyo caso
podría tener más fácil obtener la autorización dado que hay antecedentes de
cesión e importación de datos.

En todo caso, voy a ir preparando las peticiones a ambos medios para poder
usar estos conjuntos de datos en concreto.

[1] https://i.imgur.com/LC6SVZP.jpg
[2] https://i.imgur.com/bgCZ5Wc.jpg
[3]
http://pandora.girona.cat/viewer.vm?id=0002396766=4=ca=hemeroteca

El sáb., 20 oct. 2018 a las 7:59, dcapillae ()
escribió:

> Citar una fuente en un trabajo académico o en un artículo de la Wikipedia
> no
> es lo mismo que reutilizar una información y citar la fuente, que es lo que
> se pretende. En OSM no usamos las fuentes como se usan en un trabajo
> académico o en la Wikipedia: no consultamos fuentes y luego creamos un
> trabajo original de investigación o un artículo de Wikipedia de elaboración
> propia, igualmente original. En el caso del periódico, nosotros tomamos una
> información que no nos pertenece, que no es generada por nosotros, y la
> reproducimos (sin permiso) por otros medios, autorizando su reutilización
> para fines para los que quizás no tengamos derecho, como puede ser el uso
> comercial. Eso es algo más que citar una fuente. O mejor dicho, no es lo
> mismo que citar una fuente (en un trabajo académico).
>
> Como decía Miguel en un mensaje previo:
>
>
> Miguel Sevilla-Callejo wrote
> > Recuerda que el espíritu original de OSM está en que nosotros generemos
> > nuestra propia información espacial [...] Es más, si no podemos
> contrastar
> > ínsito esa información quizá no tenga cabida en la base de datos que es
> > OSM.
>
> Si lo que dice el periódico lo comprobamos por nosotros mismos y lo subimos
> a OSM, entonces no habría problema. En ese caso, la información compartida
> en OSM no sería la generada por el periódico, sino la generada por
> nosotros.
>
> Si no está claro si una información se puede reutilizar, creo que lo mejor
> sería presuponer que no se puede usar y, en todo caso, tratar de contactar
> con el titular de la información para conocer las condiciones de uso y
> pedir
> autorización si fuese necesario. Muchas fuente publicadas bajo condiciones
> de licencia Creative Commons, supuestamente con vocación de ser
> reproducibles, generan no pocos problemas para integrarse en OSM, así que
> conviene ser prudentes con estos temas.
>
> Haría falta un abogado especialista para salir de todas las dudas que
> surgen
> cuando nos enfrentamos con la protección de los derechos de autor. Como
> probablemente pocos de nosotros seamos especialistas en ese campo, sugiero
> seguir la estrategia más conservadora, no usar ninguna información que no
> sea pública o recopilada directamente por nosotros sobre el terreno, y usar
> sólo fuentes expresamente autorizadas o claramente compatibles sin duda
> alguna con la ODbL.
>
>
>
> -
> Daniel Capilla
> OSM user: dcapillae
> --
> Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-at] Neue Rechtschreibung von Wiener Straßennamen

[Robert Kaiser]

Andreas Geyer-Schulz schrieb:

Leider habe ich zu diesem Thema im Forum oder in der Mailingsliste keine
klärende Diskussion gefunden. (Ein wenig steht bei diesem
Kartenkommentar [4].) Es gibt einige Straßen, die davon betroffen sind.


Die Rechtschreibregeln (insbesondere Dinge wie die Verwendung von "ß") 
gelten explizit nicht für Eigennamen. Es gilt die Schreibung vor Ort. 
Also, was am Straßenschild steht - und hoffentlich steht das selbe auf 
der Wiener Mehrzweckkarte (die hier sicher höhere Priorität hat als das 
BEV).


KaiRo


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

Re: [OSM-talk-fr] Piscine municipale vs piscine privée

[marc marc]

Le 20. 10. 18 à 12:04, Paul Desgranges a écrit :
>>- 71 qui ont déjà un tag leisure
> on n'a pas du tout les mêmes résultats
> 62 amenity=swimming_pool and leisure=*

62 ou 71 sur 7000 c'est franchement la même chose :)
osm n'est pas statique, le fait que qlq cas ont été corrigé à la main
en 12h ne change rien fondamentalement.
et si tu fais la stat ce soir, il n'en restera plus, parce qu'au lieu
de compter par 3 fois le nombre exact, je vais les corriger,
c'est plus efficace :)

>> cela fait environ 7000 à modifier en leisure=swimming_pool.
> 2- J'enlèverais
> nommés 
> traiter individuellement)
> building
> leisure=sports_centre
> leisure=*

C'est cela (+ la taille) qui a été retiré pour arriver à 7000.

maintenant si tu préfères corriger tous ces cas à la main
avant de toucher aux 7000, pourquoi pas.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Piscine municipale vs piscine privée

[Paul Desgranges]

Le 19/10/2018 à 10:35, Noémie Lehuby a écrit :


Salut Paul,
On est quasiment d'accord !
Mon plan était de commencer par la proposition de Marc de transformer 
toutes les amenity=swimming_pool en leisure=swimming_pool comme 
première étape.
Puis de faire ce que tu décris, mais sur les leisure=swimming_pool, 
puisque comme tu l'as indiqué, il y a aussi des leisure=swimming_pool 
qui devraient être leisure=sports_centre.


Noémie


Bon et bien on est presque d'accord globalement  :-)
J'essaye de bien comprendre jusqu'au bout cette histoire ... tout n'est 
pas encore clair sur ce qu'on veut faire et dans quel ordre



marc marc a écrit :
résumé de la modif automatique proposée en France
en tenant compte de tous les suggestions :
7371 amenity=swimming_pool
- 71 qui ont déjà un tag leisure


Par exemple déjà on n'a pas du tout les mêmes résultats (à quelques 
unités près comme c'est pas exactement au même moment, ça serait une 
explication mais là c'est un peu plus que ça)
62 amenity=swimming_pool and leisure=* in France 
https://overpass-turbo.eu/s/CWm
6 amenity=swimming_pool and leisure=sports_centre in France 
https://overpass-turbo.eu/s/CWe


 >- 272 avec un tag name

161 amenity=swimming_pool and name=* https://overpass-turbo.eu/s/CUk
15 amenity=swimming_pool and name=Piscine https://overpass-turbo.eu/s/CWo
3 amenity=swimming_pool and name="Piscine privée" 
https://overpass-turbo.eu/s/CWp

0 amenity=swimming_pool and name="piscine privée"


- 39 avec un tag building


113 amenity=swimming_pool and building=yes in France 
https://overpass-turbo.eu/s/CUI 
121 amenity=swimming_pool and building=* in France 
https://overpass-turbo.eu/s/CWx


>- 18 avec une surface dams josm areasize > 2000m2
>cela fait environ 7000 à modifier en leisure=swimming_pool.
>pas d'objection ?


>Pour le reste, je m’abstiens de le faire en automatique,
>mais je donne volontiers un coup de main pour le faire
>à la main, en regardant chaque objet.
>>Le 19. 10. 18 à 08:42, Paul Desgranges a écrit :
>>/    les "amenity=swimming_pool + name=*" /
>>/ en "leisure=sports_centre + /
>>/sport=swimming"
/>Je doute que tu puisses tirer une conclusion aussi binaire de
>la présence d'un nom, j'ai déjà croisé souvent des name=piscine privée

Il y a effectivement 3 name="Piscine privée" et 0 name="piscine privée", 
mais
16 name="Piscine" où effectivement le contributeur a mis dans le champ 
"nom"

ce qui relève plutôt d'une "description".

>Je pense que pour ceux là, soit on les inclus dans le groupe général
>(c'était supposé être un bassin, si c'est faux, cela reste faux)

Justement je crois pas, on peut pas supposer quoi que ce soit,
ceux qui ont taggué amenity=swimming_pool ne souhaitaient pas forcément 
tagguer un bassin, il y a de tout la-dedans


>soit c'est plus raisonnable de les charger dans josm et de faire
>un contrôle humain pour mettre l'éventuel faux nom dans description
>et tag d'accès plutôt que de changer le sens en centre sportif
>car c'est une supposition hasardeuse.

>>/"amenity=swimming_pool + name!=*" /
>>/ en "leisure=swimming_pool" /
>critère "tag name" ajouté ci dessus pour l'édition de masse

Plutôt "*pas de* tag name" ? Sachant que quand il y a un tag name c'est 
plus vraisemblablement une piscine publique, les piscines privées n'ont 
pas de nom sauf les cas déjà évoqués, par exemple

15 amenity=swimming_pool and name=Piscine https://overpass-turbo.eu/s/CWo
3 amenity=swimming_pool and name="Piscine privée" 
https://overpass-turbo.eu/s/CWp

0 amenity=swimming_pool and name="piscine privée"
3 amenity=swimming_pool and name="watched swimming" 
https://overpass-turbo.eu/s/CWZ

 qui sont des espaces de baignade surveillée sur un plan d'eau

 >>/"amenity=swimming_pool + 
building=yes" /

>>/ en "leisure=sports_centre /
>- critère "pas de tag building" ajouté pour l'édition de masse.
>- Mais convertir en centre sportir uniquement sur la base de la présence
>d'un tag building, c'est se tromper lorsqu'un bassin est couvert avec
>un bâtiment en dur donc je passe mon tour pour faire cette modif là
>en automatique (mais je ne suis pas vexé si quelqu'un veux faire
>autrement à ma place)

C'est pas clair pour moi, je ne vois pas ce cas que tu exposes, "bassin 
couvert par un bâtiment en dur", il doit y en avoir dès comme ça, mais où ?
Là "amenity=swimming_pool + building=yes" le contributeur n'avait pas 
l'intention de tagguer un simple bassin de piscine mais bien une piscine 
publique


>il y en a que 39 et un risque d'erreur trop élevé que pour justifier
113 amenity=swimming_pool and building=yes in France 
https://overpass-turbo.eu/s/CUI 
121 amenity=swimming_pool and building=* in France 
https://overpass-turbo.eu/s/CWx


>de le faire à l'aveugle.
>>/Mais là, a-t-on la possibilité de faire une requête overpass turbo 
pour /

>>/les 

Re: [Talk-it] [Alberi monumenmtali] Quale licenza?

[Martin Koppenhoefer]

sent from a phone

> On 19. Oct 2018, at 15:35, Andrea Musuruane  wrote:
> 
> Non mi sembra corretto usare il tag name per indicare il nome volgare 
> dell'albero. Il  tag name deve essere usato per nomi propri, non per quelli 
> comuni (infatti non scriviamo name=Fontanella o name=Bar).


si usa species:it
in realtà la cosa migliore è mettere la specie in latino con “species”, e 
volendo un link a wikidata.

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

Re: [OSM-talk] OpenStreetMap Carto release v4.16.0

[Stephan Knauss]

Bitmap based pre-rendered maps are always a trade-off.

If you are looking for a more "google-like" dynamic map, then check out the 
vector tiles based maps which support search for amenities and can dynamically 
display features.

The arguments had been cited already by the map maintainers. You can always 
fork and render your own map. Free OSM data allows you to do so.

Stephan


On October 20, 2018 10:17:43 AM GMT+02:00, Maarten Deen  wrote:
>On 2018-10-20 03:33, Daniel Koć wrote:
>> W dniu 19.10.2018 o 07:39, Maarten Deen pisze:
>> 
>>> Does this mean that amenity=atm only gets rendered in zoom 19 and
>>> higher? If so, why? It is now rendered from 17 onward, shops get
>>> rendered from 18 onward.
>>> It seems to me that atms are at least as important as shops.
>> 
>> 
>> Yes, you get it right. I based this solution on size principle,
>because
>> this is the only universal rule I know that helps managing the mess
>> which is best visible on z17 in big, well mapped cities. Here are two
>> real life illustrations of the problem with small amenities I gave
>> during long and hot discussion:
>> 
>> 
>>
>https://github.com/gravitystorm/openstreetmap-carto/pull/3372#issuecomment-423373856
>>
>https://github.com/gravitystorm/openstreetmap-carto/pull/3372#issuecomment-426308795
>
>With that argument you can delete all icons because "well mapped cities
>
>are cluttered". Maybe there needs to be done something about that, 
>instead of not showing information everywhere.
>There is not even a hint that there is something now. Shops already get
>
>mapped as dots first, now atms are just invisible except at the highest
>
>zoom.
>Sorry, but IMHO this is a bad change.
>
>Maarten
>
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Carto release v4.16.0

[Daniel Koć]

W dniu 20.10.2018 o 10:17, Maarten Deen pisze:
> With that argument you can delete all icons because "well mapped
> cities are cluttered". 


This is a straw man argument. No icons has been removed and it was not
even proposed, it's just about moving initial zoom levels and it's
enough. "Small" is not "invisible".


> Maybe there needs to be done something about that, instead of not
> showing information everywhere.


Nothing proposed in a month long debate was more objective and
universal. But maybe your proposition would be better - who knows, you
can try.

It would help to resolve urban/outdoor issue, but we currently don't
know how to detect when we could render things earlier without
cluttering the space.


> There is not even a hint that there is something now. Shops already
> get mapped as dots first, now atms are just invisible except at the
> highest zoom.


Of course there is no hint, since objects of this size just don't belong
here. The same is true for benches for example.


> Sorry, but IMHO this is a bad change.

Time will tell. However it took me many months to understand how we
could deal with non obvious problems and size rule seems to be the best
tool to avoid "importance wars".


-- 
"Excuse me, I have some growing up to do" [P. Gabriel]



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

Re: [OSM-talk] OpenStreetMap Carto release v4.16.0

[Maarten Deen]

On 2018-10-20 03:33, Daniel Koć wrote:

W dniu 19.10.2018 o 07:39, Maarten Deen pisze:


Does this mean that amenity=atm only gets rendered in zoom 19 and
higher? If so, why? It is now rendered from 17 onward, shops get
rendered from 18 onward.
It seems to me that atms are at least as important as shops.



Yes, you get it right. I based this solution on size principle, because
this is the only universal rule I know that helps managing the mess
which is best visible on z17 in big, well mapped cities. Here are two
real life illustrations of the problem with small amenities I gave
during long and hot discussion:


https://github.com/gravitystorm/openstreetmap-carto/pull/3372#issuecomment-423373856
https://github.com/gravitystorm/openstreetmap-carto/pull/3372#issuecomment-426308795


With that argument you can delete all icons because "well mapped cities 
are cluttered". Maybe there needs to be done something about that, 
instead of not showing information everywhere.
There is not even a hint that there is something now. Shops already get 
mapped as dots first, now atms are just invisible except at the highest 
zoom.

Sorry, but IMHO this is a bad change.

Maarten

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

Re: [OSM-talk-fr] Changesets étranges

[Jean-Christophe Becquet]

Le 19/10/2018 07:25, Jean-Christophe Becquet a écrit :
> Le 18/10/2018 11:56, François Lacombe a écrit :
>> Je pense que ces changesets sont à reverter, les names sont assez subjectifs
>> https://www.openstreetmap.org/changeset/52265291
>> https://www.openstreetmap.org/changeset/52265046#map=13/44.0609/6.1159
>>
>> Qu'en pensez-vous ?

Bonjour,

Décidément, cretinus alpinae est très zélé.

Les aménagements décrits dans ce changeset
https://www.openstreetmap.org/changeset/63576817

n'existent tout simplement pas sur le terrain, pas même le premier coup
de truelle.

cretinus alpinae utilise les tags
highway=service
service=proposed

et un autre contributeur a ajouté
description=Projet

Est-ce que
highway=proposed
proposed=service

ne serait pas plus approprié ?

D'après
https://wiki.openstreetmap.org/wiki/FR:Key:proposed

Bonne journée

JCB
-- 
Wikimedia Commons
http://www.apitux.org/index.php?2015/07/06/249-wikimedia-commons

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
BP 32 - 04001 Digne-les-Bains Cedex
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===

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