[Talk-us] Need someone in the south to review an edit

[Paul Johnson]

Brandify put up a rather suspicious mass deletion
 recently.  I suspect that
one of their customers stopped paying/had a term contract that expired and
Brandify mass-deleted the entire chain.  But it is possible that the chain
went out of business and their website is still active.  Could I get
someone in the south to take a look at this and see if locations near you
that was deleted closed?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] City of Portsmouth, Virginia Building/Address Import

[Jonah Adkins]

Hey OSM, 

I'd like to propose an import of GIS data for Portsmouth, Virginia. The source 
data is provided by the State of Virginia via the Virginia Geographic 
Information Network (VGIN) under a  compatible license for import. There’s 
around 49,000 buildings, most of which include an address and building type. 
This import has been discussed on the OSM Slack Virginia channel with 
pre-review of the available sample data and I anticipate local mapper support 
with the import process. Conflation with existing OSM data will happen during 
the import.

For more information and a sample OSM file, see: 

Github -> https://github.com/jonahadkins/portsmouth-osm-imports
Wiki -> 
https://wiki.openstreetmap.org/wiki/City_of_Portsmouth_Buildings/Address_Import


This message has been cross-posted in Talk-US, Imports-US, & Imports. 

Also please rememberer SOTMUS is around the corner - talks, scholarships and 
more! -> https://2019.stateofthemap.us

Thanks, 

Jonah 
jonahadkins.com
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [talk-au] Tagging frontage roads

[Graeme Fitzpatrick]

On Thu, 13 Jun 2019 at 13:38, David Wales  wrote:

> I only heard the term from the Wiki.
> They were originally tagged as service roads, but I changed them to
> residential roads,
> because that's what I thought the Wiki was suggesting:
> https://wiki.openstreetmap.org/wiki/Frontage_road
>
> I'm open to changing them back to service.
>

I reckon highway=residential would be fine if they have houses on them, or
just have them as highway=service if they're the "service" roads alongside
a highway.

Thanks

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

[OSM-talk-fr] taginfo fr mieux limité à la France

[marc marc]

Bonjour,

une expérimentation est en cours sur https://taginfo.openstreetmap.fr
le but est de mieux représenter les données réelles en France
étape 1 : filtrer l'extrait pbf sur la frontière réelle
au lieu de filtrer sur un contour simplifié à X mètres du réel.
Avantages : les stats taginfo correspondent mieux à la réalité.
C'est étape est faite.

les objets à cheval sur la frontière (forêt, bâtiment mais aussi
itinéraire de bus) restent comme avant inclus dans les stats fr

ä suivre (dans un ordre non définit)
- porter la modif sur le serveur de donwload
- supprimer les tag "discardable" qui n'apportent pas d'info
- supprimer les frontières non-fr mais incluse dans l'extrait fr
parce qu'elles ont un morceau en commun

n'hésitez pas à signaler d'éventuelle anomalie,
souhaits ou autres

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

Re: [Talk-it] Source dubbio

[Andy Townsend]

On 07/06/2019 21:55, Andy Townsend wrote:

On 23/05/2019 10:19, Ivo Reano wrote:

Nessuna novità?
Ho un sacco di survey da inserire, ma mi trovo continuamente con cose 
che potrebbero essere revertate...



...


The feedback that I've had so far is in favour of reverting this 
imported data, possibly without a redaction.



If we do decide to revert it then we'll probably find that some data 
has been modified by other users since.  With this data we can again 
do one of two things:


 1. Leave it, because newer edits by other users may have corrected
problems
 2. Force through the revert, which will undo good mapping by people
unconnected with the import here.



If we're not redacting then I'd suggest we do (1) rather than (2) here.

Before I start on this procedure, has anyone else got any comments?

Best Regards,

Andy Townsend, on behalf of OSM's Data Working Group


(traduzione automatica)

Il feedback che ho avuto fino ad ora è a favore del ripristino di questi 
dati importati, possibilmente senza una redazione.



Se non stiamo correggendo, suggerirei di fare (1) piuttosto che (2) qui.

Prima di iniziare questa procedura, qualcun altro ha ricevuto dei commenti?



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

Re: [OSM-talk] Terminate Facebook rights under ODbL (Andy Mabbett )

[Simon Poole]

The ODbL (like for example the CC licences too) does not allow
sub-licencing and stipulates that every licensee is licensed directly by
the OSMF.

Am 13.06.2019 um 19:10 schrieb Eugene Alvin Villar:
> On Thu, Jun 13, 2019 at 6:17 PM Nuno Caldeira
> mailto:nunocapelocalde...@gmail.com>>
> wrote:
>
> [...] OSMF is the licensor [...]
>
>
> Well, if we really want to be strict about it, AFAIK, Facebook did not
> get their map data directly from OSMF but rather through Mapbox.
> Mapbox got their data directly from OSMF and are re-releasing their
> OSM derivative database and produced works as vector tiles and static
> map images via their APIs and SDKs. This would mean that it is the
> responsibility of Mapbox to notify Facebook that FB is not in
> compliance with the ODbL.
>
> However, I really think it would be interesting to see if OSMF
> bypassing Mapbox and directly contacting one of Mapbox's clients is a
> valid legal avenue to pursue attribution violations.
>
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk-fr] créer des way en réutilisant les nœuds existant

[marc marc]

bons conseils, nous allons tester.

le but est de corriger les erreurs du fichier opendata (ce
sont les limites administrative du Kosovo) pour obtenir
un fichier d'une qualité permettant d'être proposé à l'import.
il y a beaucoup trop d'anomalies que pour faire cela à
la main, d’où le besoin d'une automatisation objectivable
comme conflate

La simplification des chemins c'est pas mieux après
la résolution des nœuds dupliqués ? sinon chacun
des 2 chemins pourrait se simplifier différemment, non ?
on aurait au final + de nœuds que nécessaire.

Merci.

Le 13.06.19 à 18:53, Jérôme Amagat a écrit :
> Je ne sais pas si j'ai tout bien compris mais avec ton exemple on peut 
> utiliser le plugin conflation en sélectionnant dans la destination les 
> node et dans la ref way et node (réglage : simple et remplacer la 
> géométrie coché). après assemblage, on a bien les way qui utilise les 
> node de départ. par contre on a un problème là où dans la ref il y a 2 
> node l'un sur l'autre, cela reste 2 node. Il y a aussi le problème non 
> pressent dans ton exemple mais qui peut poser problème c'est que le 
> plugin met une erreur et ne veux pas remplacer la géométrie d'un node si 
> il est utilisé par un way.
> 
> Je comprend pas bien ce que vous voulez faire mais je dirais que vous 
> devriez corriger le fichier ref avec l'option de JOSM outils -> 
> simplifier le chemin pour supprimer les problèmes des nodes superposés 
> ou presque. Il faut avant mettre une valeur basse 0.3 ou moins dans 
> "simplify-way.max-error" dans les réglage avancé de JOSM.
> 
> Sinon, pour le validateur et la fusion de node, il ne voit une erreur 
> que si les nodes sont à la même position mais je viens de voir que l'on 
> peut changer ça en modifiant dans les réglage de JOSM la valeur de 
> "validator.duplicatenodes.precision" qui est à 0.0 est qu'il faudrait 
> mettre à quelque chose de très petit. à tester, je n'ai jamais utiliser 
> mais avec un petit test je dirais qu'il faut une valeur de 0.0001 voir 
> plus petit. (c'est peut être une valeur en degré?)
> 
> si le problème c'est de garder les id osm des objets, conflation 
> remplace la géométrie et garde les id, lorsque l'on assemble un way, les 
> id des node sont aussi conserver pour les node qui reste au même endroit 
> ou presque, mais pas si le node est utiliser par un autre way, dans ce 
> cas conflation crée un nouveau node.
> plus d'outils -> remplacer la géométrie fait la même chose mais là il 
> faut avoir copier la nouvelle géométrie dans le calque de destination 
> puis sélectionner les 2 ways, l'ancien et le nouveau, et faire remplacer 
> la géométrie.
> Dans les 2 cas, josm demande pour garder l'appartenance aux relations
> 
> 
> 
> Le jeu. 13 juin 2019 à 00:32, marc marc  > a écrit :
> 
> Bonjour,
> 
> avec Guillaume on tente d'ajouter des way sans créer de nœuds
> inutiles cad qu'on a dans josm 2 calques :
> - un qui contient des way avec plein de nœuds dupliqués ou quasi
> - l'autre qui contient tous les nœuds nécessaire et sans doublon
> grâce au pluging conflate sur les nœuds
> Et on veux transférer les ways d'un calque à l'autre mais
> en utilisant les nœuds déjà présent dans la destination.
> 
> conflate détecte facilement les ways manquant, mais à l'assemblage
> il recrée des nœuds inutilement, y compris quand ils sont exactement
> à la bonne position. soucis de paramètre ?
> OU
> faire un "conflate" qui traite les nœuds en même temps que les way?
> on n'a pas trouvé comment.
> OU
> autre outil + adapté ?
> par ex le validateur josm sait réparer le problème des nœuds dupliqués
> exactement à la même position mais pas si la position est légèrement
> différente, quelqu'un a déjà fait une règle pour avoir une détection
> de noeud ultra proche ?
> 
> exemple simplifié
> 
> https://framadrop.org/r/4whuwfaoPi#9SfgmKr/bokHFHy1542BYkqnCvxdxI0YVyArNJRnIsY=
> le but est de transférer le triangle et le carré du calque ref
> vers destination sans provoquer de nœuds dupliqués dans destination
> les nœuds sont volontairement exactement à la même position
> entre les 2 calques pour simplifier le problème.
> 
> une idée ?
> 
> PS: le but réel est d'utiliser l'opendata d'un pays pour
> préparer l'ajout des frontières administratives manquantes
> mais le fichier opendata est plein de nœuds dupliqués ou quasi
> dupliqués et il faut évidement réutiliser un maximum de nœuds
> de la frontière nationale existante dans osm
> 
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

[OSM-talk-fr] Proposition - RFC - Armement des supports de lignes aériennes

[François Lacombe]

Salut à tous,

En chemin pour le SOTM, pourquoi ne pas traduire une super proposition wiki
en cours ?
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Lines_attachements

Celle-ci concerne, sous un nom un peu barbare, la manière dont les lignes
(électriques mais pas que) sont attachées à leur support.
C'est une proposition "de service", servant à décharger la clé tower:type
de valeurs particulières puisque cette clé dépasse largement le seul
contexte de l'énergie ou de l'ancrage au support (on s'en sert pour
distinguer les tours de télécommunication des tours de chateaux...)
La clé line_attachement permet de décrire quelque chose d'assez visible
quand on a le défaut de regarder tous les poteaux qui passent.
Elle donne en outre encore plus de valeur aux données relatives aux
pylônes, poteaux et autres supports.

S'est engagée depuis l'année dernière une discussion qui a amené pas mal de
maturation sur la version anglaise, il était maintenant possible de la
traduire pour le français en vue de la voter

Vous pouvez en prendre connaissance et me remonter vos observations si vous
en avez.

Bonne fin de semaine

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

[Talk-pt] Relações em urbanização

[Alexandre Badalo]

Boas,


Tenho estado a mapear a minha terreola, agora uma das coisas que falta
são os edificios, eu não tenho bem a certeza como mapear as
urbanizações, fiz uma assim
https://www.openstreetmap.org/changeset/71231696 , não sei se as
relações são necessárias, e se sequer estão bem feitas, podem verificar?


No caso dos edificios com lojas em baixo e casas em cima, como devo
proceder ao mapeamento das lojas/restaurantes/etc? deixo como node?
Coloco uma relação ao edificio?


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

[talk-ph] Pista ng Mapa 2019

[Eugene Alvin Villar]

Hello all!

Are you a fan of open geo datasets and free and open-source geospatial
software and tools? Pista ng Mapa ("Feast of Maps"), the open mapping
conference in the Philippines, will be held at Foundation University,
Dumaguete this coming 1–3 August 2019. Registration is free! (Travel and
accommodations not included.)

Please register and reserve your slot here:
https://ti.to/PistaNgMapa/2019

We would like to thank our generous sponsors:
Kaart – http://kaartgroup.com/
Grab – https://www.grab.com/
Mapillary – https://www.mapillary.com/

We would also like to acknowledge the support of our host:
Foundation University – https://www.foundationu.com/

See you there!
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [OSM-talk-fr] Osmose erreurs#1270

[David Crochet]

Bonjour

Le 13/06/2019 à 12:44, lenny.libre a écrit :
Est-ce le "area=yes" qui perturbe Osmose où une erreur de ma part ? 



Si le chemin arrive à une aire, cela nécessite la continuité dudit 
chemin à l'intérieur de l'aire.


Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] Osmose erreurs#1270

[deuzeffe]

On 13/06/2019 17:45, marc marc wrote:


Donc erreur à signaler à osmose ?


à la place d'osmose, j'ignorerais tout ce qui touche
aux highway surfacique, c'est trop immature.
mais sinon oui tu peux essayer de proposer que freed
fasse une rustine sur la rustine pour avoir moins d'anomalie.


Et résoudre l'anomalie en "Faux positif", ça le fait pas ?

--
deuzeffe

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

[Talk-it] R: R: R: Casette captazione acqua

[angelo mornata]

Scusa Martin ma pensavo che la questione fosse chiusa, a questo punto è meglio 
spiegare quando vengono fatte e come, queste protezioni.
Quando si decide che un a sorgente d'acqua può avere un interesse strategico 
per veicolare/captare l'acqua in un gruppo di /baite/case/villaggi/acquedotti 
ecc.. ecc... la prima cosa che si fa e' proteggerla da defecazioni animali o 
peggio ancora da animali morti che potrebbero decomporsi nelle fonte stessa, in 
pratinca si fanno 4 muri e un tetto in cemento che possono avere le seguenti 
dimensioni: altezza 1 mt., profontità 1 mt., lunghezza 1mt, così come possono 
essere + grandi...
Dentro queste protezioni c'è una vasca di sedimentazione (che intercetta 
eventuale sabbia), e un tubo posizionato più in alto del fondo della vasca che 
veicola l'acqua (capta) a baite/case/villaggi/acquedotti ecc..ecc...
In lamiera non le ho mai viste.
Quindi oltre "man_made=water_works" cosa dobbiamo mettere?

Grazie
Angelo


Da: angelo mornata 
Inviato: mercoledì 5 giugno 2019 12:09
A: talk-it@openstreetmap.org
Oggetto: [Talk-it] R: R: Casette captazione acqua

Si è vero non è un vero e proprio serbatoio, ho corretto.

Grazie Alessandro

Angelo



Da: Alessandro P. via Talk-it 
Inviato: mercoledì 5 giugno 2019 08:06
A: talk-it@openstreetmap.org
Cc: Alessandro P.
Oggetto: Re: [Talk-it] R: Casette captazione acqua

Il 04/06/19 18:21, Francesco Ansanelli ha scritto:
> Buonasera,
> non sono sicuro di aver capito di cosa si tratta, ma immagino sia
> qualcosa tipo:
> https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dreservoir_covered
> Francesco

reservoir_covered è per l'immagazzinamento. In questo caso direi
man_made=water_works

https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dwater_works

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

Re: [OSM-talk-fr] Réseau de transport : intégration OD

[deuzeffe]

Comme j'ai beaucoup embêté Noëmie, elle m'a proposé de relire le tuto. 
qu'elle allait faire à ce propos. DOnc, WIP, je dirais. Mais que ça ne 
t'empêche pas d'attaquer la chose par l'autre face ;)


On 13/06/2019 14:42, marc marc wrote:

quelqu'un a déjà regardé s'il y avait une page sur le wiki
qui décrit les étapes ? ou c'est à faire ?

Le 11.06.19 à 08:27, lenny.libre a écrit :

c'est bien d'avoir la séquence des arrêts que donne le fichier.


même pour cela, ce serrait agréable d'avoir un outil + intégré :

dans un premier temps, avoir une simple conversion automatique
des fichiers tel que ce qui est fait à la main

dans un deuxième temps
- si la ligne existe en opendata/gtfs mais pas dans osm, avoir
une anomalie et la possibilité de créer la relation "en un clic"
en convertissant la séquence opendata/gtfs en une liste de membre
d'arrêt pour la relation
- si la relation existe déjà dans osm, comparaison du nombre d'arrêt
(avec sûrement une difficulté du aux variantes de lignes sans doute
pas identique entre opendata/gtfs... mais faudrait sans doute
qu'au moins une variante osm arrive au même nombre de l'opendata)

perso je ne crée pas assez de ligne manquante à cause de cela
___
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] Terminate Facebook rights under ODbL (Andy Mabbett )

[Nuno Caldeira]

Eugene I already pointed that to Mapbox that some of their clients are not
complying with ODbL and even their terms of service. They didn't reply
either.
Mapbox TOS https://docs.mapbox.com/help/how-mapbox-works/attribution/

Text attribution

The text attribution contains at least three links: © Mapbox, ©
OpenStreetMap and Improve this map. This attribution is strictly required
when using the Mapbox Streets tileset due to OpenStreetMap's data source
ODbL license. Some other Mapbox-provided tilesets require additional
attribution which is stored in the TileJSON of the tileset.
When do you have to provide attribution?

Maps using Mapbox map designs or data supplied by Mapbox must display both
the Mapbox wordmark and text attribution. This includes:

Maps using a Mapbox template style such as Mapbox Streets, Mapbox
Outdoors or Mapbox Light, or a style derived from those styles.
Maps using a Mapbox tileset, such as Mapbox Streets, Mapbox Terrain,
and Mapbox Satellite.

You must also display the Mapbox wordmark if your map uses a custom style
or custom data hosted by Mapbox. (This is the case for most maps built with
Mapbox Studio.) If you do not use Mapbox designs or data supplied by
Mapbox, you may omit text attribution.

If your map does not use Mapbox designs, data, hosting, or other Mapbox
APIs, Mapbox does not require you to provide attribution in either form.



A quinta, 13/06/2019, 18:10, Eugene Alvin Villar 
escreveu:

> On Thu, Jun 13, 2019 at 6:17 PM Nuno Caldeira <
> nunocapelocalde...@gmail.com> wrote:
>
>> [...] OSMF is the licensor [...]
>>
>
> Well, if we really want to be strict about it, AFAIK, Facebook did not get
> their map data directly from OSMF but rather through Mapbox. Mapbox got
> their data directly from OSMF and are re-releasing their OSM derivative
> database and produced works as vector tiles and static map images via their
> APIs and SDKs. This would mean that it is the responsibility of Mapbox to
> notify Facebook that FB is not in compliance with the ODbL.
>
> However, I really think it would be interesting to see if OSMF bypassing
> Mapbox and directly contacting one of Mapbox's clients is a valid legal
> avenue to pursue attribution violations.
>
>
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Terminate Facebook rights under ODbL (Andy Mabbett )

[Eugene Alvin Villar]

On Thu, Jun 13, 2019 at 6:17 PM Nuno Caldeira 
wrote:

> [...] OSMF is the licensor [...]
>

Well, if we really want to be strict about it, AFAIK, Facebook did not get
their map data directly from OSMF but rather through Mapbox. Mapbox got
their data directly from OSMF and are re-releasing their OSM derivative
database and produced works as vector tiles and static map images via their
APIs and SDKs. This would mean that it is the responsibility of Mapbox to
notify Facebook that FB is not in compliance with the ODbL.

However, I really think it would be interesting to see if OSMF bypassing
Mapbox and directly contacting one of Mapbox's clients is a valid legal
avenue to pursue attribution violations.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] créer des way en réutilisant les nœuds existant

[Jérôme Amagat]

Je ne sais pas si j'ai tout bien compris mais avec ton exemple on peut
utiliser le plugin conflation en sélectionnant dans la destination les node
et dans la ref way et node (réglage : simple et remplacer la géométrie
coché). après assemblage, on a bien les way qui utilise les node de départ.
par contre on a un problème là où dans la ref il y a 2 node l'un sur
l'autre, cela reste 2 node. Il y a aussi le problème non pressent dans ton
exemple mais qui peut poser problème c'est que le plugin met une erreur et
ne veux pas remplacer la géométrie d'un node si il est utilisé par un way.

Je comprend pas bien ce que vous voulez faire mais je dirais que vous
devriez corriger le fichier ref avec l'option de JOSM outils -> simplifier
le chemin pour supprimer les problèmes des nodes superposés ou presque. Il
faut avant mettre une valeur basse 0.3 ou moins dans
"simplify-way.max-error" dans les réglage avancé de JOSM.

Sinon, pour le validateur et la fusion de node, il ne voit une erreur que
si les nodes sont à la même position mais je viens de voir que l'on peut
changer ça en modifiant dans les réglage de JOSM la valeur de
"validator.duplicatenodes.precision" qui est à 0.0 est qu'il faudrait
mettre à quelque chose de très petit. à tester, je n'ai jamais utiliser
mais avec un petit test je dirais qu'il faut une valeur de 0.0001 voir plus
petit. (c'est peut être une valeur en degré?)

si le problème c'est de garder les id osm des objets, conflation remplace
la géométrie et garde les id, lorsque l'on assemble un way, les id des node
sont aussi conserver pour les node qui reste au même endroit ou presque,
mais pas si le node est utiliser par un autre way, dans ce cas conflation
crée un nouveau node.
plus d'outils -> remplacer la géométrie fait la même chose mais là il faut
avoir copier la nouvelle géométrie dans le calque de destination puis
sélectionner les 2 ways, l'ancien et le nouveau, et faire remplacer la
géométrie.
Dans les 2 cas, josm demande pour garder l'appartenance aux relations



Le jeu. 13 juin 2019 à 00:32, marc marc  a
écrit :

> Bonjour,
>
> avec Guillaume on tente d'ajouter des way sans créer de nœuds
> inutiles cad qu'on a dans josm 2 calques :
> - un qui contient des way avec plein de nœuds dupliqués ou quasi
> - l'autre qui contient tous les nœuds nécessaire et sans doublon
> grâce au pluging conflate sur les nœuds
> Et on veux transférer les ways d'un calque à l'autre mais
> en utilisant les nœuds déjà présent dans la destination.
>
> conflate détecte facilement les ways manquant, mais à l'assemblage
> il recrée des nœuds inutilement, y compris quand ils sont exactement
> à la bonne position. soucis de paramètre ?
> OU
> faire un "conflate" qui traite les nœuds en même temps que les way?
> on n'a pas trouvé comment.
> OU
> autre outil + adapté ?
> par ex le validateur josm sait réparer le problème des nœuds dupliqués
> exactement à la même position mais pas si la position est légèrement
> différente, quelqu'un a déjà fait une règle pour avoir une détection
> de noeud ultra proche ?
>
> exemple simplifié
>
> https://framadrop.org/r/4whuwfaoPi#9SfgmKr/bokHFHy1542BYkqnCvxdxI0YVyArNJRnIsY=
> le but est de transférer le triangle et le carré du calque ref
> vers destination sans provoquer de nœuds dupliqués dans destination
> les nœuds sont volontairement exactement à la même position
> entre les 2 calques pour simplifier le problème.
>
> une idée ?
>
> PS: le but réel est d'utiliser l'opendata d'un pays pour
> préparer l'ajout des frontières administratives manquantes
> mais le fichier opendata est plein de nœuds dupliqués ou quasi
> dupliqués et il faut évidement réutiliser un maximum de nœuds
> de la frontière nationale existante dans osm
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose erreurs#1270

[osm . sanspourriel]

Osmose n'aime pas les rues qui s'arrêtent au bord de l'eau.

Si des barques y accostent c'est bien que c'est un quai ! Certes dont la
longueur est celle de la largeur de la route. Le wiki
 dit de ne pas
taguer comme un point mais certains le font.

Si la zone d'accostage est plus longue que la route est large, tu peux
allonger le quai. Car rien n'indique la profondeur du quai : c'est une
propriété pour les bateaux et pas pour les terrestres !

Sinon tu peux mettre un slipway.

Sauf que pour moi une cale descend au niveau de l'eau ce qui ne semble
pas être le cas.

Amha, noexit est juste puisque c'est vu d'un point de vue terrestre.
Sinon partout tu peux t'envoler ;-).

Jean-Yvon


Le 13/06/2019 à 17:09, lenny.libre - lenny.li...@orange.fr a écrit :


J'ai une autre signalement similaire mais le point
https://www.openstreetmap.org/node/4803417553#map=19/45.43701/12.32896
est à la jonction entre "highway=pedestrian" et le bord du canal : si
je mettais un “noexit” se ne serait pas tout à fait juste, il n'y a
pas de quai, la rue s'arrête au droit du canal et des barques privées
y accostent.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-ro] name= pentru drumurile comunale, de ce?

[Razvan Radulescu]

Desi va spun sa faceti cum vreti pana la urma, totusi propun sa o faceti 
selectiv daca se poate si sa lasati pe anumite drumuri comunale numele adaugate 
de echipa lui Anatolie. Sunt o gramada de sate si catune care nu au niciun nume 
la strada lor principala ( la astea ma refer) si din aceasta cauza,  adaugarea 
acelor nume pe DC-uri nu interfereaza cu un posibil nume care inca nu a fost 
adaugat pe harta. In principal doar la Drumurile Judetene ar trebui sterse. 
Oricum de atunci au mai fost adaugate in anumite localitati numele reale ale 
strazilor atat pe unele drumuri judetene cat si pe comunale. Si sa nu stergeti 
cu revertul si ce s-a adaugat corect dupa aceea...

Trimis din Mail pentru Windows 10

De la: Strainu
Trimis: joi, 13 iunie 2019 12:34
Către: OSM Romania
Subiect: Re: [Talk-ro] name= pentru drumurile comunale, de ce?

Da Anatolie, toți cei de mai sus au spus același lucru: fără denumiri
pe drumuri unde nu există. Doar Răzvan a zis că poate, poate, doar
pentru DC-uri. Faceti voi revert sau e nevoie să ne organizăm noi?

Strainu

În mar., 4 iun. 2019 la 17:47, Anatolie Golovco
 a scris:
>
> Gabriel
>
> Hai reciteste tot ce scrie mai sus, tempereaza vocabularul si capacitatea de 
> generare de conflict.
> Eu in inteleg ca istoric toata comunicarea pe talk-ro a fost construita doar 
> cu atacuri la persoana si comportament infect, dar cred ca e timpul asta se 
> se schimbe.
>
> Daca voi toti vreti sa stergem numele de pe DC, asta usor poate fi organizat. 
> Dar incetati cu amentitarile de revert. Dincolo de nume pe reteaua de drumuri 
> au fost facute foarte multe imbunatatiri in geometrii. Vrei sa le faci si lor 
> revert? Asta deja o sa fie vandalizare.
>
> Mai mult respect comunitate, mai mult respect si comunicare.
>
> Anatolie
>
>
>
> On Mon, Jun 3, 2019 at 3:15 PM Gabriel Sebastian Moise 
>  wrote:
>>
>> Cum poti sa treci gunoiul asta de denumire in localitate  ?
>> https://www.openstreetmap.org/edit?node=463178672#map=17/44.80146/25.99798
>>
>> Ai idee ce scrie pe Cartile de Identitate ale localnicilor de acolo, sau si
>> din alte localitati unde ati facut porcariile astea de denumiri ?
>>
>> Predesti si nr de Casa . In alte localitati este Strada Principala Nr. x   ,
>> iar in altele chiar nume de strada unde e cazul.
>>
>> Cum ai putut sa treci DJ101G-Gara Prahova ? Care gara fratele meu? Aia la
>> care ajungi pe un track , cu caruta la 2 , 3 km rin padure  ? Zici de gara
>> de parca e la marginea localitatii si e gen primarie !
>> Ai impresia ca in OSM, sau pe vreun soft de navigatie, o sa zica, dupa Gara
>> faci la dreapta  ?
>>
>> Ai mai vazut pe vreo harta gen Here, TomTom, etc.. caterinca asta  ?
>> Am sa cer si eu parerea lui Octavian de Here, a lui Andrei, Felix , etc.
>> sa vedem ce or sa zica si ei de isprava asta !
>>
>> Am sa o socotesc o gluma . Si am rugamintea sa faceti curat pe unde ati
>> facut asemenea glume , ca sa nu pun sa fie sterse toate modificarile de
>> genul, de la cel mai inalt nivel de moderare !
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Romania-f5425034.html
>>
>> ___
>> Talk-ro mailing list
>> Talk-ro@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ro
>
>
>
> --
>
> Best Regards
> Anatolie GOLOVCO
> +373 79270954
>
> ___
> Talk-ro mailing list
> Talk-ro@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ro

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

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

Re: [OSM-talk-fr] Osmose erreurs#1270

[marc marc]

Le 13.06.19 à 17:09, lenny.libre a écrit :
> 
> Le 13/06/2019 à 12:53, marc marc a écrit :
>> Le 13.06.19 à 12:44, lenny.libre a écrit :
>>> Est-ce le "area=yes" qui perturbe Osmose
>> c'est la conclusion à laquelle je suis arrivée
> 
> Donc erreur à signaler à osmose ?

à la place d'osmose, j'ignorerais tout ce qui touche
aux highway surfacique, c'est trop immature.
mais sinon oui tu peux essayer de proposer que freed
fasse une rustine sur la rustine pour avoir moins d'anomalie.

> J'ai une autre signalement similaire mais le point 
> https://www.openstreetmap.org/node/4803417553#map=19/45.43701/12.32896 
> est à la jonction entre "highway=pedestrian" et le bord du canal : si je 
> mettais un “noexit” se ne serait pas tout à fait juste, il n'y a pas de 
> quai, la rue s'arrête au droit du canal et des barques privées y accostent.

il n'y a pourtant aucun mode de transport qui continue de l'un à l'autre
tu peux faire du multimodal (arriver en voiture, continuer en barque)
mais pour chacun des modes l'un des 2 objets (la rue et le canal),
c'est sans issue à ce point là. là aussi à voir si osmose ne devrait
pas simplement s'abstenir.
Mais avec cette logique, il y a plein de cas :
un sentier piéton qui termine en bordure de la pelouse d'un parc 
n'empêche pas de continuer à se balader dans le parc

perso j'aurais modifié la donnée dans osm, considérant que la rue
ne se jette pas dans le canal et que donc il n'y a pas de noeud commun
ou s'il y a un noeud commun, c'est une barrière (une vrai barrière
ou un muret de qlq cm pour éviter que l'eau ne coule dans la rue)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose erreurs#1270

[lenny.libre]

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

Le 13.06.19 à 12:44, lenny.libre a écrit :

Est-ce le "area=yes" qui perturbe Osmose

c'est la conclusion à laquelle je suis arrivée


Donc erreur à signaler à osmose ?

J'ai une autre signalement similaire mais le point 
https://www.openstreetmap.org/node/4803417553#map=19/45.43701/12.32896 
est à la jonction entre "highway=pedestrian" et le bord du canal : si je 
mettais un “noexit” se ne serait pas tout à fait juste, il n'y a pas de 
quai, la rue s'arrête au droit du canal et des barques privées y accostent.



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

Re: [OSM-talk-fr] Réseau de transport : intégration OD

[Christian Quest]

SI ce sont des informations publiques, en principe oui. <- y'a bien un SI
en début de phrase ?

Mais on voit bien que c'est pas si simple... vu qu'en remontant à la source
on découvre c'est publié en ODbL :(

J'ai signalé à data.gouv que le moissonnage perdait l'info de licence.


Le mer. 12 juin 2019 à 07:44, Jean-Christophe Becquet  a
écrit :

> Le 12/06/2019 07:24, Christian Quest a écrit :
> > Si ce sont des informations publiques, l'absence de licence équivaut à
> > la Licence Ouverte, qui n'est qu'une reprise de la Loi (oui, nos lois
> > sont plus fortes qu'un texte de licence).
>
> Bonjour,
>
> Tu veux dire que pour une information publiée sans mention de licence,
> je peux me prévaloir d'une Licence Ouverte ?
>
> J'avais bien intégré l'obligation d'opendata par défaut à laquelle sont
> désormais tenues les collectivités mais il me semble qu'il faut un
> accord explicite pour que la licence s'applique.
>
> Merci
>
> JC
> --
> Digne : SIG libres à l'IUT avec les étudiants - mercredi 19 juin
> https://iut.univ-amu.fr/presentation-logiciels-libres-sig-19-juin-2019
>
> ==APITUX : le choix du logiciel libre==
>
> APITUX - Jean-Christophe Becquet
> 2 chemin du Tivoli - 04000 Digne-les-Bains
> 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
>


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

Re: [OSM-talk-fr] Nombres d'appareils connectés avec un seul compte OSM

[marc marc]

Le 11.06.19 à 16:46, Vincent Bergeot a écrit :
> c'est laborieux par la suite pour le changement de mot de passe !

quel besoin nécessite de changer de mdp ?
c'est pour éviter que les participants utilisent
le compte pour contribuer après le cours ?

L'api n'a pas l'air d'avoir de méthode pour le changement de mdp,
mais cela ne devrait pas être trop compliqué de faire un script
qui se connecte à une série de compte et change le mdp
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-pt] Estuário do Tejo & linha de costa (Topo Lusitania)

[Hugo Valentim]

OK. Compreendi o histórico.

A coastline, de facto, é renderizada a partir de informação tratada em separado 
(os shapefiles publicamente disponíveis são supostamente actualizados a cada 12 
horas, não tenho a certeza se o openstreemap.org se actualiza com a mesma 
frequência…).

Ora, do meu ponto de vista, no instante actual, a vantagem em usar a coastline 
para demarcar o Estuário reside precisamente no facto de ela não ser, do ponto 
de vista da edição do mapa, um polígono. O único requisito para não a “quebrar” 
é manter uma linha contínua de segmentos, um procedimento automático existe < 
https://osmcode.org/osmcoastline/> que se encarrega de gerar os polígonos de 
“água” com o devido limite de 2000 pontos (em obediência à API v6) – por 
coincidência ou não gerando o mesmíssimo resultado do plugin Split do QGIS. 
Provavelmente os ficheiros  também poderão 
ser usados na geração de mapas para Garmin.

O uso da coastline também admite a renderização do natural=shoal (áreas a 
descoberto na maré baixa, o que não sucede se a margem for definida como 
riverbank), embora em última análise isso seja uma especificidade do 
mapnik-carto.

Por outro lado, há ainda, por inerência, a questão da exclusão/inclusão (imagem 
inversa) nos polígonos da terra. A linha de água do Estuário do Tejo 
actualmente acaba em frente ao Cais do Sodré (Gargalo do Tejo).

Assim, no instante presente, talvez não fosse má ideia incorporar o Mar da 
Palha simultaneamente na coastline e no multipolígono Iberian Peninsula?

Cump.s,
H. Valentim


De: talk-pt-requ...@openstreetmap.org
Enviado: 11 de junho de 2019 13:00
Para: talk-pt@openstreetmap.org
Assunto: Talk-pt Digest, Vol 113, Issue 4

Today's Topics:

   1. Re: Estuário do Tejo & linha de costa (Topo Lusitania Lusitania)
   2. Re: Estuário do Tejo & linha de costa (Topo Lusitania Lusitania)

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

Re: [OSM-talk-fr] Réseau de transport : intégration OD

[marc marc]

quelqu'un a déjà regardé s'il y avait une page sur le wiki
qui décrit les étapes ? ou c'est à faire ?

Le 11.06.19 à 08:27, lenny.libre a écrit :
> c'est bien d'avoir la séquence des arrêts que donne le fichier.

même pour cela, ce serrait agréable d'avoir un outil + intégré :

dans un premier temps, avoir une simple conversion automatique
des fichiers tel que ce qui est fait à la main

dans un deuxième temps
- si la ligne existe en opendata/gtfs mais pas dans osm, avoir
une anomalie et la possibilité de créer la relation "en un clic"
en convertissant la séquence opendata/gtfs en une liste de membre 
d'arrêt pour la relation
- si la relation existe déjà dans osm, comparaison du nombre d'arrêt
(avec sûrement une difficulté du aux variantes de lignes sans doute
pas identique entre opendata/gtfs... mais faudrait sans doute
qu'au moins une variante osm arrive au même nombre de l'opendata)

perso je ne crée pas assez de ligne manquante à cause de cela
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData

[Grigory Rechistov via Talk-se]

Hej på er alla!
Förlåt mig för längre tystnad på den här listan, var upptagen med livet/jobbet
och orkade bidra till OSM endast sent på kvällarna då var det inte bästa 
tillfällen
att kolla/svara mejl.
Låt mig svara på alla förfrågor/kommentarer som nyligen samlades i tråden.
> Jag såg att Åstorps kommun laddades upp. Det blev inte så bra:
> http://grillo.users.openstreetmap.se/a1dd1280bc521ca2725f8b8daaee11f993800871.jpg
Nej, det gjorde det inte. Hoppas att det inte skapade för mycket besvär att 
rätta till.
> Jag håller på att städa och önskar att du kunde låta bli att importera så 
> nära tätort.
Jag försöker alltid städa bostadsområden eftersom man förväntar sig 
att se bättre objektsuppställning där, och det går enklare att manuellt rita där
med renare slutresultat. Men ibland slippar ändå någonting över byggnader.
> Dessutom önskar jag att du hade någon form av varningssystem så du inte 
> laddar upp överlappande data.
Om ett område är omringat med "landuse=residential" undvikas det
helt i mina skript. Ifall det inte finns en sådan polygon (vilket sker ganska 
ofta men inte är något fel på det) raderar jag datat runt orten manuellt om jag 
ser det.
Jag vill nu också inkludera en tiotal meter "buffert" runt enstaka byggnader 
på ett liknande sätt hur det nu är med vägar och järnvägar. Detta ska hjälpa 
förhindra tätorters nedsmutsning även om någonting inte är omringat med 
"residential".
Åstorps kommuns import var ett försök att lära mig hur det gick 
med på att importera NMD-datat i en kommun som huvudsakligen var täckt av 
åkermark och som redan var 50%-kartlagd.
Jo, det visade sig att bli jobbigt att justera polygoner längs flera långa vägar
och att se till att alla små detaljer läggas rätt. Men det var möjligt i alla 
fall,
fastän med fler misstag än önskades.
I framtiden vill jag använda olika parameter vid databearbetningen för olika
kommuner beroende på vilken typ markanvändning råder i just det område, t ex
filtrera mer aggressivt åkermark men inte skogar.
> eller markerar upp tomtmark som grassland.
Jo, olika slags "gräs" har blivit ett riktigt huvudvärk. Precis som man varnade 
mig förut! Att skilja mellan bland annat "golf_course", "landuse=grass" och 
"natural=grassland" kräver alltid lite tanke. I Åre kommun brukar jag behöva
tagga om nästan alla "gräs"-ytor som hed (natural=heath) i fjällen. Men inte 
allt; tomtmark bör stanna som "landuse=grass".
Jag ber er om hjälp med att tagga det rätt där jag gjorde ett misstag. Särskilt 
gäller det när det blivit "natural=grassland" istället för "landuse=grass", dvs
nära tätorter…
>Noterade att relationen https://www.openstreetmap.org/relation/9623607 inte 
>renderar. 
> Kan bero på att den korsar sig själv i denna punkt
Oj, förlåt. Visst försöker jag inte låta sådana tabbar förekomma. 
Självkorsningarna
är det främsta egna problem i importdatat. Det brukar vara runt 50 tillfällen 
per
ruta i början, och jag validerar och fixar och validerar igen och fixar tills 
det inte 
finns några alls. Men ett par gånger per million nya noder kan man ju förbise en
nod :-).
Som redan var sagt och som uppfattades från början, är kommuner med flertal 
tätorter ett vanskligt mål för importen. Däremot blir glesbebyggda områden 
riktigt mer detaljerade med mindre risk för att skapa konflikter (och förarga 
några människor i processen).
För närvarande finns det drygt 60 rutor i Åre kommun för att importera kvar.
Jag håller på att slutföra med den kommunen inom några veckor innan sommarens 
semestersäsong börjar. Sedan får vi se hur man vidare kan förbättra befintliga
algoritmer, datakvalité, minska manuellt arbete osv med ny erfarenhet man fått.
Jag upptäckte också att sjöar/tjärnar/våtmark i fjällen inte är lika 
fullständigt
kartlagda som jag trodde förut. Fler sjöar saknas helt och de som finns på 
kartan
har ofta grova ungefärliga konturer. De motsvarande polygoner som finns i 
NMD-datat är noggrannare men just nu importerar vi inte vatten ytor. 
Så mycket att förbättra till!
P.S. Mina allmänna tankar på hela importprocessen beskrev jag i ett inlägg här:
https://atakua.org/w/landuse-conflation.html. Jag vill också skapa en mer 
formell
beskrivning för att hjälpa med framtidens importer här:
https://wiki.openstreetmap.org/wiki/Conflation/Land_Cover . Men just nu är sidan
nästan tom.
 
 Среда, 12 июня 2019, 12:50 +03:00 от Johan Emilsson :
>Tack! Det var där skon klämde.
>
>/Johan
>
>On Wed, 12 Jun 2019 at 11:01, Snusmumriken < snusmumriken.map...@runbox.com > 
>wrote:
>>On Wed, 2019-06-12 at 10:50 +0200, Johan Emilsson wrote:
>>> Hallå,
>>> 
>>> Kollar på importerat material för Åre.Noterade att relationen 
>>>  https://www.openstreetmap.org/relation/9623607 inte renderar. Blir
>>> dock inte klok på varför inte.
>>
>>Kan bero på att den korsar sig själv i denna punkt
>>https://www.openstreetmap.org/node/6499163329
>>
>>
>>___
>>Talk-se mailing list
>>Talk-se@openstreetmap.org

Re: [OSM-talk-fr] Osmose erreurs#1270

[marc marc]

Le 13.06.19 à 12:44, lenny.libre a écrit :
> Est-ce le "area=yes" qui perturbe Osmose

c'est la conclusion à laquelle je suis arrivée
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Osmose erreurs#1270

[lenny.libre]

Bonjour,

Osmose me signale une erreur "Jonction imparfaite, joindre le nœud ou 
utiliser l’attribut “noexit” si sans issue"


Alors que le nœud 
https://www.openstreetmap.org/node/4827349244#map=19/45.43644/12.32431 
est à la jonction d'un "highway=pedestrian" et d'un 
"highway=pedestrian"+ "area=yes"


Est-ce le "area=yes" qui perturbe Osmose où une erreur de ma part ?

cordialement

Leni


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

Re: [OSM-talk] Terminate Facebook rights under ODbL (Andy Mabbett )

[Nuno Caldeira]

Martin, i obviously agree about the usage of usage data, that's the point
of OpenStreetMap. Makes me proud to see it being used more and more as an
alternative of Google. But the license has requirements that must be
fulfill.

I know they are already in breach, however as pointed on 9.4 c), the
licensor (OSMF) must notify them to be considered permanetly terminated.
they are not complying with the license neither with the guidelines that
OSMF have set and made public. When we adopted ODbL, im sure 9.4 c) was
evaluated,despite you mentioning its not OSMF duty to pursue license
violations, however OSMF is the licensor and ODbL mentions the Licensor can
permanently terminate the license. As I, as a contributor have requested
multiple times, pointed out the copyright page, the license and the
guidelines as they keep ignoring, this is the only solution for them to
have their license permanetly terminated, unless they comply in 30 days
after being notified.

A quarta, 12/06/2019, 12:02, Martin Koppenhoefer 
escreveu:

> sent from a phone
>
> > On 9. Jun 2019, at 15:45, Nuno Caldeira 
> wrote:
> >.
> > As mentioned on the blog, i already asked facebook several times to
> comply. They stopped replying. I'm not expecting a reply, i'm just sharing
> this on the mailing list.
>
>
> I guess you are expecting a reply from the OpenStreetMap-Foundation
> board of directors or them publicly taking a position? Because this is
> the n+1th time that unsatisfactory attribution (or completely missing
> in the case of mini maps) by Facebook is raised here, and AFAIR there
> was never an official statement by the board (members of the board may
> have replied individually and with personal statements). I would
> really welcome a clear statement from board, or at least one that
> explains that board members have different opinions on this, or why it
> takes them so long to say anything about it.
>
> People have contributed to OSM under the Contributor Terms, where OSMF
> acknowledged they would only distribute the data under the ODbL or
> another free and open license chosen by the active contributors. Not
> pursuing license violations (and not even attempting to do anything
> against it) is against the spirit of the whole license idea and raises
> questions about the validity of the Contributor Terms agreement.
>
> As you have cited, for the abusers the situation is defined in the
> license text, "9.0 Termination of Your rights under this License", and
> by using the OSM data without attribution (as confirmed also by
> Facebook in the email you have shared), their license is already
> terminated, no notification necessary ("9.1 Any breach by You of the
> terms and conditions of this License automatically terminates this
> License with immediate effect and without notice to You.").
> On the other hand, I believe most of us are not interested in
> terminating the use of our data by them, we are happy for everyone
> using it, it is the purpose of the project to create useful data. What
> we want is simply the required attribution. Noone can use a
> substantial part of the db without giving attribution.
>
> In some way it is also in the interest of any of our data users that
> there is attribution to OSM, because if the OSM community grows, it
> will result in more accurate and up to date map data.
>
> Cheers,
> Martin
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-es] Cambio masivo calles 30

[Alejandro Moreno]

Este cambio de normativa se aplicó hace unos meses en Madrid y en su día se
estuvo discutiendo por aquí como implementarlo.
Al final no se llegó a ninguna conclusión de importación pero sí se habló
de poner la etiqueta
source:maxspeed=

implicit


Así, si en el futuro cambia la normativa están identificados los maxspeed
que realmente no cambiarían ya que están limitados por una señal de los que
son genéricos y están definidos por la normativa.



El jue., 13 jun. 2019 a las 11:17, F. Verdú ()
escribió:

> Buenos días.
> Valencia acaba de cambiar la velocidad máxima a 30 en calles de un sólo
> carril por sentido. Hay un mapa oficial con esto, pero no parece que sea
> exportable y lo veo inviable por ser calles, no nodos aislados. ¿Hay alguna
> manera rápida de añadir esto? Realmente seria por diferencia, es decir
> poner todas las residential con maxspeed=30 y luego mano quitar las
> excepciones.
> Gracias.
> ___
> 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-ro] name= pentru drumurile comunale, de ce?

[Strainu]

Da Anatolie, toți cei de mai sus au spus același lucru: fără denumiri
pe drumuri unde nu există. Doar Răzvan a zis că poate, poate, doar
pentru DC-uri. Faceti voi revert sau e nevoie să ne organizăm noi?

Strainu

În mar., 4 iun. 2019 la 17:47, Anatolie Golovco
 a scris:
>
> Gabriel
>
> Hai reciteste tot ce scrie mai sus, tempereaza vocabularul si capacitatea de 
> generare de conflict.
> Eu in inteleg ca istoric toata comunicarea pe talk-ro a fost construita doar 
> cu atacuri la persoana si comportament infect, dar cred ca e timpul asta se 
> se schimbe.
>
> Daca voi toti vreti sa stergem numele de pe DC, asta usor poate fi organizat. 
> Dar incetati cu amentitarile de revert. Dincolo de nume pe reteaua de drumuri 
> au fost facute foarte multe imbunatatiri in geometrii. Vrei sa le faci si lor 
> revert? Asta deja o sa fie vandalizare.
>
> Mai mult respect comunitate, mai mult respect si comunicare.
>
> Anatolie
>
>
>
> On Mon, Jun 3, 2019 at 3:15 PM Gabriel Sebastian Moise 
>  wrote:
>>
>> Cum poti sa treci gunoiul asta de denumire in localitate  ?
>> https://www.openstreetmap.org/edit?node=463178672#map=17/44.80146/25.99798
>>
>> Ai idee ce scrie pe Cartile de Identitate ale localnicilor de acolo, sau si
>> din alte localitati unde ati facut porcariile astea de denumiri ?
>>
>> Predesti si nr de Casa . In alte localitati este Strada Principala Nr. x   ,
>> iar in altele chiar nume de strada unde e cazul.
>>
>> Cum ai putut sa treci DJ101G-Gara Prahova ? Care gara fratele meu? Aia la
>> care ajungi pe un track , cu caruta la 2 , 3 km rin padure  ? Zici de gara
>> de parca e la marginea localitatii si e gen primarie !
>> Ai impresia ca in OSM, sau pe vreun soft de navigatie, o sa zica, dupa Gara
>> faci la dreapta  ?
>>
>> Ai mai vazut pe vreo harta gen Here, TomTom, etc.. caterinca asta  ?
>> Am sa cer si eu parerea lui Octavian de Here, a lui Andrei, Felix , etc.
>> sa vedem ce or sa zica si ei de isprava asta !
>>
>> Am sa o socotesc o gluma . Si am rugamintea sa faceti curat pe unde ati
>> facut asemenea glume , ca sa nu pun sa fie sterse toate modificarile de
>> genul, de la cel mai inalt nivel de moderare !
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Romania-f5425034.html
>>
>> ___
>> Talk-ro mailing list
>> Talk-ro@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ro
>
>
>
> --
>
> Best Regards
> Anatolie GOLOVCO
> +373 79270954
>
> ___
> Talk-ro mailing list
> Talk-ro@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ro

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

[Talk-es] Cambio masivo calles 30

[F . Verdú]

Buenos días.
Valencia acaba de cambiar la velocidad máxima a 30 en calles de un sólo
carril por sentido. Hay un mapa oficial con esto, pero no parece que sea
exportable y lo veo inviable por ser calles, no nodos aislados. ¿Hay alguna
manera rápida de añadir esto? Realmente seria por diferencia, es decir
poner todas las residential con maxspeed=30 y luego mano quitar las
excepciones.
Gracias.
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [talk-cz] Upgrade OsmHiCheck

[Tom Ka]

Tak shrnuti:
- Locus dokaze bez problemu pracovat pouze s internimi ikonami coz je
vybrana cast ikon Nicolase Molleta a ikonami pro zarizeni Garmin.
Cokoliv pridavaneho je pak problem (musi se doinstalovat, vyzaduje
specialni cast v GPX, je vyrazne pomalejsi pri zpracovani)

Nakonec jsem vyresil moznosti mit vic sad ikon, aktualne jsou k
dispozici 2 - jedna pro interni Locus (vychozi), jedna pro Garmin:

https://osm.fit.vutbr.cz/OsmHiCheck/gp/?get_gpx=locus (nebo bez
parametru icons)
https://osm.fit.vutbr.cz/OsmHiCheck/gp/?get_gpx=garmin

(samozrejme lze kombinovat s proximity a pozdeji i filtry)

Aktualni sady a jejich prirazene ikony jsou videt na zacatku v poli $sym_icons
https://openstreetmap.cz/git/tom.k/OsmHiCheck/commit/6a4511f33e24c2ba5e41d6cfa3d9774c42af5f6b

Kazda sada obsahuje ikony pro:
- jen tourism=information
- mame fotku ale nemame ref v OSM - je treba upravit v OSM
- rozcestnik
- infopanel
- mapa
- ostatni

Vzhledem k vyberu nejsou ikony vzdy idealni, ale snazil jsem se aspon
nejakou logiku do toho dostat, zaroven byl cil mit to barevne trochu
sladene (locus).

Toz testujte, problemy hlaste :-)

Bye

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

Re: [OSM-talk-fr] Bombarder mieux avec l'apprentissage automatique

[osm . sanspourriel]

Le 10/06/2019 à 14:10, Yves P. - yves.prat...@gmail.com a écrit :

(...)

Je suis plus inquiet, dans un premier temps, des utilisations
commerciales de "big brother" (Google/Facebook...).


Comme Yves a bien apprécié le lien, je vous en fait bénéficier :

https://tube.ac-lyon.fr/videos/watch/7f90f01e-2b9c-49de-a5d0-5c364b481023


 /Géolocalisation & MétaDonnées - Extraits de Nothing To Hide/

/C'est l'histoire de MisterX, acteur et clubber Berlinois, qui n'a rien
à cacher... enfin, c'est ce qu'il dit.../

//

/Il s'agit d'extraits du film documentaire //*Nothing to Hide*//qui
permettent de mettre en évidence le problème du partage des métadatas./

Mais il ne faut pas sous-estimer le fait qu'eux travaillent avec les
militaires//et qu'ici ou ailleurs avec certain•e•s à la porte du pouvoir
on n'est pas à l'abri d'un flicage généralisé à la Chinoise.

Jean-Yvon

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

[Talk-hr] State of the Map 2019

[hbogner]

Ide li netko na https://2019.stateofthemap.org/ ?


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