Re: [Talk-us] Parks, again

[OSM Volunteer stevea]

On Jan 3, 2018, at 5:24 PM, Greg Troxel  wrote:
> I think the National Park term causes a lot of problems.   As I see it,
> there are two kinds of places:
> 
>  1) a natural area with some accomodation for human use, which is mostly
>  natural except for a few bits.
> 
>  2) a semi-natural area which has grass and trees (instead of
>  concrete), but is fairly manicured.  In this way it is more like a
>  maintained garden than wilderness..
> 
> Both of these exist at various scales.

I hear you.  I'm listening.  This is all true.  There are also 3), 4) and many, 
many others.  Yes.

Our definition of "park" (both as humans and in OSM) is quite elastic, let's 
face it.

As you say "feel like Type 2" I think is where it fuzzies in my mind.  Parks go 
to 3, 4, even 11 and beyond.  Parks have a wide range of "experiences" besides 
1 and 2.

> A "conservation area" in my town might be only 100 acres.  You are in
> the forest, with just a cleared trail and blazes.  But at the entrance,
> there is a dirt parking lot and a sign with a map.  This is a type 1
> area with a very small (enough for 10 cars) part that almost feels a
> little type 2 (except the parking lot is barely usable), but it's so
> small we just call it type 1.

Again, I hear this, this is true, I nod my head in agreement.  There is what we 
experience in the real world and yes, that maps directly onto a tag in OSM.  
Park is that.  States use it.  Nations use it.  "Come camp here for the night 
or a week" places which are commercial use it.  It is elastic in the real world 
and many use it, as we call myriad of them by using the name park in our speech 
as a noun.  It is a wide and flexible concept in human thinking, directly 
applied to all kinds of places around the world.  By billions of us.  
Frequently.

> Whether anybody (administrator of thing or not) uses the work Park is
> not relevant at all.

Mmm, no.  We (humanity, including administrators and the people) mean something 
as we use the word "park" together in wide harmony.  That is (at least partly!) 
why we tag with the word "park."

Yes, there are "local parks with benches and grass in our city."  Yes, there 
are "national parks."  We're only up to two, right there.  Then you get to 
their various scales.  There are many more than two.

SteveA
California
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Potential vandalism in Northern California (Pokémon Go?)

[Greg Troxel]

I think the National Park term causes a lot of problems.   As I see it,
there are two kinds of places:

  1) a natural area with some accomodation for human use, which is mostly
  natural except for a few bits.

  2) a semi-natural area which has grass and trees (instead of
  concrete), but is fairly manicured.  In this way it is more like a
  maintained garden than wilderness..

Both of these exist at various scales.

Point 1 is leisure=nature_reserve, more or less.  If there is legal
protection (which is separate from what's there now), it should get
some sort of "landuse=conservation", "boundary=protected_area", or the
special kind of protected_area with an implied leisure=nature_reserve
known as boundary=national_park.

Point 2 is leisure=park.

In New England, in type 1 you are probably going to get ticks, and in
type 2 you probably aren't.

One of the real difficulties is that in areas athat are type 1, such as
a lot of state parks, and national parks, there are significant
sub-areas, often bigger than many town parks, that are very much type 2.

As an example, in Yellowstone, the 6 or so villages where there are
hotels, general stores, maybe a gas station, places with picnic tables,
boardwalks, feel like type 2.   But once you leave those pretty small
areas, you are almost in wilderness.

A "conservation area" in my town might be only 100 acres.  You are in
the forest, with just a cleared trail and blazes.  But at the entrance,
there is a dirt parking lot and a sign with a map.  This is a type 1
area with a very small (enough for 10 cars) part that almost feels a
little type 2 (except the parking lot is barely usable), but it's so
small we just call it type 1.

Whether anybody (administrator of thing or not) uses the work Park is
not relevant at all.


signature.asc
Description: PGP signature
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [talk-latam] (no subject)

[Miguel Sevilla-Callejo]

Genial,

Yo me di de alta en esta lista hoy mismo para mandar el mensaje pues creo
que solo Marco Antonio (de Cochabamba, Bolivia) escribe de vez en cuando y,
no tiene mucha actividad (no como el grupo de Telegram).

Supongo que él puede decirte más recursos comunes de la comunidad latina e
hispanohablante.

Saludos

--
 Miguel Sevilla-Callejo
from my mobile 

El 3/1/2018 20:13, "Javier Sánchez Portero"  escribió:

> Hola
>
> Me llamo Javier y llevo un tiempo contribuyendo al mapa principalmente en
> las Islas Canarias.
>
> Miguel cuenta conmigo si puedo ayudar. Los contenidos que sean comunes se
> pueden trasladar a plantillas y cada comunidad puede crear sus páginas
> incluyendo la parte común con la plantilla y a continuación el contenido
> específico.
>
> Cuando busque contactar con la comunidad hispanohablante en la Wiki no
> encontré enlaces a esta lista y al grupo de Telegram
>
> https://wiki.openstreetmap.org/wiki/ES:Wikiproyecto_Comunidad_hispana
>
> La edito y actualizo.
>
> Saludos a todos,
> Javier Sánchez
>
>
> ___
> talk-latam mailing list
> talk-latam@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-latam
>
>
___
talk-latam mailing list
talk-latam@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-latam

Re: [OSM-talk-fr] Montrer dans OSM les toponymes réels dans les différentes langues de la République française

[marc marc]

Le 03. 01. 18 à 22:19, Christian Rogel a écrit :
> Donner le nombre de name:X et de valeurs permet de relativiser les 
> tronçonnement des voies.

c'est une bonne idée de se baser sur le nombre de valeur différente
pour faire les stats.

ceci dit, sur le fond (avoir des contributeurs pour introduire 27 
langues dans osm), je me demande si le processus n'est pas 
fondamentalement inefficace.
On a vu à mainte reprise les dégâts que cela provoque régulièrement.
ne serrait-il pas plus intéressant de commencer par les objets osm qui 
ont un lien wikipedia/data en introduisant leur nom sur wikidata.
je ne suis pas un partisan inconditionnel de wikidata.
mais dans ce cas précis cela aurait les avantages :
- d'utiliser les infos déjà existante
- d'éviter d'avoir plusieurs projet qui font le même travail
- de monter en qualité.
au lieu de faire un processus manuel, il pourrait y avoir un import de 
qualité (vérifier que l'objet osm a le même nom que celui de wikidata 
(pour éviter de mettre à jour les nombreux village ou lieu-dit qui ont 
erronément le wikipedia/data de leur commune, ce qui pourrait remonter 
en anomalie).
si le nom osm match avec wikipedia/data, on importe le(s) name:xx 
pertinents selon la zone concernée.
le même code (par exemple dans osmose) pourrait servir à détecter les 
vandales, les erreurs et les futurs ajouts.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BANO / Cadastre différence nom de voie

[Christian Quest]

Effectivement, bravo Sherlock ! :)

Le 3 janvier 2018 à 21:31, Francois Gouget  a écrit :

> On Wed, 3 Jan 2018, Christian Quest wrote:
>
> > Sur le plan cadastral, il y a des libellés qui peuvent être différents de
> > ceux qu'on trouve dans FANTOIR... même si les deux sources sont la DGFiP.
> >
> > Là, il n'y a que le terrain qui peut servir à départager ces
> incohérences.
>
> Pas tout à fait. Wikipedia est très utile pour pas mal de ces
> incohérences. En l'occurrence on découvre que :
>
> * Hongerford est grosso-modo inconnu au bataillon.
>
> * Hungerford est une bourgade Anglaise qui est jumelée avec Ligueil, la
>   ville où ce trouve cette voie !
>   https://fr.wikipedia.org/wiki/Hungerford
>
> * Et la page anglaise de Ligueil confirme ce jumelage (mais rien sur la
>   page française).
>   https://en.wikipedia.org/wiki/Ligueil
>
> Donc, indépendamment de ce qui est écrit sur les panneaux, il y a de
> très fortes chances qu'Hungerford soit le nom correct.
>
>
> --
> Francois Gouget   http://fgouget.free.fr/
>Be careful of reading health books, you might die of a misprint.
>  -- Mark Twain
> ___
> 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] BANO / Cadastre différence nom de voie

[marc marc]

Le 03. 01. 18 à 21:31, Francois Gouget a écrit :
> On Wed, 3 Jan 2018, Christian Quest wrote:
> 
>> Sur le plan cadastral, il y a des libellés qui peuvent être différents de
>> ceux qu'on trouve dans FANTOIR... même si les deux sources sont la DGFiP.
>>
>> Là, il n'y a que le terrain qui peut servir à départager ces incohérences.
> 
> Pas tout à fait. Wikipedia est très utile pour pas mal de ces
> incohérences. En l'occurrence on découvre que :
> 
> * Hongerford est grosso-modo inconnu au bataillon.
> 
> * Hungerford est une bourgade Anglaise qui est jumelée avec Ligueil, la
>ville où ce trouve cette voie !
>https://fr.wikipedia.org/wiki/Hungerford
> 
> * Et la page anglaise de Ligueil confirme ce jumelage (mais rien sur la
>page française).
>https://en.wikipedia.org/wiki/Ligueil
> 
> Donc, indépendamment de ce qui est écrit sur les panneaux, il y a de
> très fortes chances qu'Hungerford soit le nom correct.

il n'y hélas pas vraiment de nom correct :)
la commune peux évidement changer le nom pour qu'il corresponde à la 
ville anglaise.
d'ici là name=le terrain (alt_name=fantoir si on veux le rendre 
accessible aux moteur de recherche)
et ajouter la ref fantoir pour permettre le match.
cela évite d'avoir le chemin en inconnu dans la page des matchs 
fantoir<>osm et qui sait peut-être un jour avoir un processus pour 
remonter à qui de droit les incohérences (c'est beau de rêver)


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

Re: [Talk-it] Auguri

[Alessandro Vitali]

Augur!!!

Il 02 Gen 2018 16:11, "XSchockingChannel"  ha
scritto:

> AUGURI A TUTTI E BUON 2018 
>
> valerio fasano
>
> Il 1 gen 2018 17:37, "Damjan Gerl"  ha scritto:
>
>> 01.01.2018 - 08:19 - Michele Malfatti:
>>
>> auguri a tutti!
>>
>> Sent from my iPhone
>>
>>
>> On 01/gen/2018, at 00:16, Andreas Lattmann  
>>  wrote:
>>
>> Auguri di Buon Anno che il 2018 sia un anno sereno, felice e di tanto 
>> mapping! 
>> Andreas Lattmann
>>
>>
>> Augur!
>>
>> Damjan
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-ee] Eesti haldusjaotus

[Manuel Hohmann]

Tere!

Panin skripti ka githubisse:

https://gist.github.com/xenos1984/83b6b2f1fd518faf1c3bd235009366ad

Minuarust oleks hea kui loogiline seos asustusüksuste ja nende omavalitsuse / 
maakonna vahel oleks ka tagides nähtav, sest neid on palju lihtsam automaatselt 
lugeda / võrrelda kui geomeetriat. Aga see ei pruugi olla praeguses formaadis 
(kuigi see on tegelikult päris lihtne), vaid võiks ka relatsioonina olla.

Geomeetria parandamiseks veel kirjutan väikest tööriista, mis näitab kaardil 
nii EHAK kui OSM asustusüksuste piire, ja millest saab EHAK piire ka GPX 
failina JOSMisse laadida. See pole veel päris valmis, aga vähemalt jagasin 
Tormi failid juba väiksemateks GPX failideks, mis on kättesaadavad siit:

http://mhohmann.dev.openstreetmap.org/eesti/haldus/{EHAK-kood}.gpx

Näiteks:

http://mhohmann.dev.openstreetmap.org/eesti/haldus/1004.gpx

Parimat,
Manuel

On 03.01.2018 15:44, Jaak Laineste wrote:

Tervitus,

Äge! Vaadates vigade hulka (5876) on käsitsi nende järjest parandamine 
lootusetu, aga siit tuleb välja mõni huvitav muster, mida saaks skriptiga ka 
parandada. Näiteks:

Kas on ikkagi vaja küladele ja omavalitsustele ülemtasemete koode 
(EHAK:countycode ja EHAK:parishcode)? Nende EHAK koodide probleem on, et need 
muutuvad alati kui piirid muutuvad, ja praegu mitme maakonna (Läänemaa, 
Pärnumaa) piiride muutumisel on kõikide omavalisuste ja tuhandete külade 
maakonnakoodid aegunud. Ei saa ka lihtsalt neid uuendada, sest samal ajal läks 
suur osa külasid Läänemaalt Pärnumaale. Suur osa vigu praegu ongi vist sealt. 
Ettepanek: andmeliialdus lõpetada ja need ülemtasemete tagid lihtsalt 
eemaldada. Sisuliselt on see is_in tüüpi tag, mida saab andmete kasutaja 
asendada geograafilise sõltuvusega. Ehk siis jääb üks maakond ja sellel on 
EHAK:code, ja kui on vaja teada küla EHAK:countycode, siis saab selle 
geograafilise sisaldumise teel tuletada. Või veel OSM-ilikum oleks luua 
relatsioon, omavalisuste hierarhiatest, aga need kasvavad päris suureks ja 
oluliseks lisatööks, kui minna külade tasemeteni. Mis arvate? Tagi masseemaldus 
on suht lihtne, saab JOSM-iga juba ära teha, pole vaja skriptidagi.

Teine huvitav asi minu jaoks oleks muutunud külanimed (enim Saaremaal), ja neid 
saaks vähemalt leida, kui mitte kohe parandada. Kahjuks neid saab vist vaid 
geomeetria järgi leida, sest ümbernimetatud külal on minuteada ka uus EHAK 
kood. Praeguses rapordis on need olemas “has no OpenStreetMap relation”, aga 
neid on raske eristada, sest seal on paljud puudu muudel põhjustel. 
Geomeetriatega EHAK koodid saab Maaameti failidest 
(http://geoportaal.maaamet.ee/est/Andmed-ja-kaardid/Haldus-ja-asustusjaotus-p119.html).

Vaatan et Tormil on https://github.com/buildig/EHAK/tree/master/geojson 
 ka olemas geomeetriatega, 
ja GIT ajalugu võiks teoorias näidata ka diffe; neid on tekstipõhiselt ikkagi päris 
raske lugeda, aga ma ei teagi ühtegi head geo-diff vahendit,  mis näitaks 
graafiliselt geomeetriate/kaardi muutusi. Muide kui git-is oleks failid .geojson 
laiendiga siis github peaks oskama neid ka kuvada otse kaardil.

Manuel, su skript ei ole githubis kasvõi gist-ina?

Jaak




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

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[osm . sanspourriel]

Désolé, quand on a le bonheur d'habiter en zone littorale, on déplore ce 
bleu vide : le rendu Mapnik est tellement plus fin (merci Christian et Cie).


Pourtant sur le côté dynamique c'est sympa.

Dans un hebdo-OSM ce site avait été signalé.

Un fond de carte muette (on a) et des fonds par langue ou vectoriels 
pour les textes ça peut être un bon compromis.


Mais le problème n'est pas tant la taille car on peut admettre que les 
principales langues ont des communautés assez grandes pour avoir un 
serveur de tuile (comme OSM-FR et OSM-DE) l'ont. Que le serveur de la 
fondation qui sert les tuiles depuis la France soit en langue locale ou 
en FR si possible, ça ne change pas grand chose en terme de bande passante.


Ou qu'on aille chercher les tuiles chez l'assos locale (ici OSM FR).

Reste que bretzel ou baguette, les pictos sont sans doute aussi dans la 
couche à adapter (fr ou fr-FR).


Là, sans vectoriel ça craque rapidement. Sauf à dire fr=fr-FR et que 
fr-CA sera seulement sur le Canada.


Ou à faire du GRIB qui est un vectoriel qui se cache (grille).

Le 03/01/2018 à 10:42, Christian Quest - cqu...@openstreetmap.fr a écrit :
Rendu vectoriel... et mapcat est un très bel exemple de ce qu'on peut 
faire avec les données OSM + wikipédia.


Le 3 janvier 2018 à 10:40, Bruno > a écrit :


Le 03/01/2018 à 10:25, Marc Gemis a écrit :

Connaissez-vous https://www.mapcat.com ?
- OSM data
- clic gauche
- des noms en langue locale et Anglais.

m.

Je ne connaissais pas.
Pour le changement de langue et vu le choix important, j'imagine
qu'il n'y a pas un rendu par langage ? c'est quoi le mécanisme
technique ?

2018-01-02 23:32 GMT+01:00 marc marc
>:

Bonsoir,

Le 02. 01. 18 à 23:10, Cédric Frayssinet a écrit :

Quand on passe de GMaps à OpenStreetMap.org, je trouve
que l'on perd
beaucoup à ne pas pouvoir cliquer (avec le bouton gauche)

il est clair qu'un clic droit serrait beaucoup pratique et
intuitif.

- interroger les objets

petit raccourcit : afficher l'adresse
cela ne te propose souvent le bon objet.

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





___
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


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

Re: [Talk-it] disused:

[Cascafico Giovanni]

Il 03/gen/2018 12:52, "demon.box"  ha scritto:
>
> ciao, vorrei sistemare (il mio) utilizzo non corretto del tag disused=yes
> visto che il wiki
>
> http://wiki.openstreetmap.org/wiki/IT:Key:disused:
>
> parla chiaro dicendo che è disincentivato a favore del prefisso disused:
>
> sono sincero che non ho ancora capito perchè sia disincentivato
>

La pagina che hai linkato mi risulta in disuso ;-)

In ogni caso il problema é che il semplice tag disused=yes non si sa a
quale degli altri tag faccia riferimento. A meno che non si stia parlando
di oggetti mono-tag, questa soluzione non é applicabile.

> ma a parte questo mi trovo in difficoltà quando ad esempio ho un edificio
> che palesemente non è più utilizzato ma non è nemmeno un rudere come
faccio?
> non posso fare disused:building=yes perchè la caratteristica del building
> c'è ancora...

Disused é proprio adatto a questo caso, wiki in inglese:
"Use the disused: lifecycle

prefix
 on tags that relate
to features that are in a reasonable state of repair but which are
currently unused."
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[OSM-talk-fr] Montrer dans OSM les toponymes réels dans les différentes langues de la République française

[Christian Rogel]

J’ai poursuivi les recherches et j’ai trouvé un minimum de 27 langues (ou 
géolectes) susceptibles d’être cartographiées dans la République française.
Certaines sont curieusement peu présentes comme le corse et surtout l’occitan 
(33 départements français).

Donner le nombre de name:X et de valeurs permet de relativiser les 
tronçonnement des voies. 

Liste des codes de langues mise à jour  avec nb de name:X et nb de valeurs au 
2-01-18 : 

Codes ISO 639
Arpitan > name:frp  190 ; 190
Basque > name:eu  2 424 ; 2 240
Breton > name:br  28 170 ; 18 861
Catalan > name:ca  5788 ; 5 561
Corse > name:co  206 ; 206
Créole guyanais > name:gyn
Créole martiniquais et créole guadeloupéen > gcf  540 ; 426
Créole réunionais > name:gcr  0
Flamand occidental > name:vls  38 ; 38
Francique > name:frk  0
Maoré (Mahorais) > name:swb  2
Normand > name:nrf  0 (code provisoire name:fr-x-norman à déclasser 11)
Occitan > name:oc   3 669 ; 3 669
Picard > name:pcd 40
Tahitien > name:ty  122 ; 81

Codes provisoires actifs
Franc-comtois > name:fr-x-fc 17
Gallo > name:fr-x-gallo 4

Codes provisoires proposés :
Angevin > name:fr-x-angevin
Berrichon > name:fr-x-ber
Bourbonnais > name:fr-x-bourbon
Bourguignon > name:fr-x-brg
Champenois > name:fr-x-cham
Lorrain > name:fr-x-lor
Orléanais > name:fr-x-orlean
Poitevin > name:fr-x-poit
Saintongeais > name:fr-x-saint
Tourangeau > name:fr-x-tour

Sources : Wikipedia, Taginfo et tables des codes ISO 639 




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

Re: [Talk-us] Potential vandalism in Northern California (Pokémon Go?)

[OSM Volunteer stevea]

On Jan 3, 2018, at 4:00 AM, Andy Townsend  wrote:
> Currently the wiki page 
> https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dpark defines an OSM 
> "leisure=park" using a few words, and illustrates it with a picture of part 
> of Central Park in New York.  It then goes on to say that "leisure=park" 
> shouldn't be used for national parks.  It uses Yosemite at 
> http://www.openstreetmap.org/#map=10/37.8230/-119.5060 as an example national 
> park ( http://www.openstreetmap.org/relation/1643367 for info ).
> 
> I'd suggest that the state and county parks in CA such as for example Joseph 
> D Grant https://www.openstreetmap.org/relation/3003169 are less like Central 
> Park than they are like Yosemite.   They might not be close enough to warrant 
> a "boundary=national_park" tag, and some other tag (some sort of 
> protected_area?) might be more appropriate, but they're definitely not an OSM 
> "leisure=park" in a "does it quack like a duck" sense as per 
> https://wiki.openstreetmap.org/wiki/Duck_tagging.  On Joseph D Grant someone 
> has added a "park:type=county_park" tag to try and help data consumers 
> distinguish it from other "leisure=park"s, but that doesn't really say 
> anything about what it's like, just who looks after it.

While this is talk-us and not argue-us, I don't want an argument; it is dialog 
that allows us to reach consensus.  I quote exactly those "few words" in our 
wiki to define a park:  "A park is an area of open space provided for 
recreational use, usually designed and in semi-natural state with grassy areas, 
trees and bushes. Parks are often but not always municipal."  (There is a bit 
more about being fenced and/or closed at night, not germane here).  I think we 
both can agree that Joseph D Grant Park (JDG) in California meets that 
definition.  The photo of Central Park in NYC is something we can also agree is 
exemplary of what is meant by a park, but any such example will necessarily be 
different in many ways from every other park, large or small, municipal or 
otherwise.  I emphasize our wiki says "parks are not always municipal."  This 
is the case with JDG, so I re-affirm here and now its leisure=park tag as 
correct.  Having "Park" in its name seems an obvious companion to this 
statement.

Yes, there is an additional section about "National Parks."  It says "Parks in 
isolated, rural locations (namely areas called "National Parks") are 
(different)."  While I cannot disagree that National Parks ARE "different" than 
the implied definition above (they have a national operator instead of 
municipal, they offer outstanding, world-class opportunities to recreate and 
enjoy natural beauty...) the contradiction implied is not exclusionary.  In 
other words, just because national parks are implied as different from 
"municipal" parks (those might be state, county, city, neighborhood, religious 
and/or private) it does not mean that a large municipal park that might "more 
resemble" a national park isn't a park.  A major issue I have with your 
approach is that "in isolated rural locations" is a slightly fuzzy definition, 
so we might never agree on where a "hard disambiguation" between these two 
(rather arbitrary, in fact) categories bifurcates.

Having seriously scratched my head about this for almost 9 years, I noticed 
that problem/ambiguities seem to stem from this rather artificial bifurcation 
into exactly TWO categories of park:  "national" and "otherwise, not national." 
 This is clearly over-simplistic given the world's myriad parks and their 
administration.  It is destined to fail both in the minds of OSM volunteers who 
"want to do the right thing" (tag parks properly) as well as renderers trying 
to shoehorn all parks into "park" or "national park," when there are so many 
other park-like or actual park-like entities.  In 2009, (along with Apo42's 
useful habit of tagging with "park_type=county_park" (et al)), I posited the 
idea that park boundary rendering could benefit from different colors of 
dashing depending on the jurisdiction of the park.  Quoting from my wiki user 
page,

"This would be similar to how boundary=national_park creates a dashed-green 
boundary, but with different colored dashing for different levels of 
jurisdiction, from local playgrounds to national parks, or even UN World 
Heritage sites. There are many complex overlapping park boundaries of various 
levels of jurisdiction in California, especially in very far northern 
California. The intent is to communicate these in a way that the OSM community 
both accepts and finds pleasing to the eye so that even map consumers 
uninitiated with the sometimes subtle semiotics of cartographic jurisdiction 
can visually parse complex park boundaries with ease."

As that strays a LONG way from Pokémon Go Vandalism (PGV), I acknowledge it may 
be time to break out this discussion of how to tag JDG into another (titled) 
thread.

We agree that additional tags of 

Re: [Talk-it] disused:

[Cascafico Giovanni]

Un building può essere tante cose... bulding=yes non significa che sia
un'abitazione civile, ma semplicemente un edificato. Se vuoi indicare che
non ci si abita più, devi prima assegnargli un valore residence, house,
apartments, residential ecc e poi sostituirlo con yes: la history indicherà
l'evoluzione di cui hai bisogno.

Il giorno 3 gennaio 2018 14:23, demon.box  ha scritto:

> cascafico wrote
> > Il building resta building=yes. É l'eventuale sua funzione che va in
> > disuso: amenity, landuse, leisure ecc.
>
> ok ma quindi se per esempio è semplicemente un'abitazione civile a non
> essere più utilizzata non ho modo di indicarlo...
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] BANO / Cadastre différence nom de voie

[Francois Gouget]

On Wed, 3 Jan 2018, Christian Quest wrote:

> Sur le plan cadastral, il y a des libellés qui peuvent être différents de
> ceux qu'on trouve dans FANTOIR... même si les deux sources sont la DGFiP.
> 
> Là, il n'y a que le terrain qui peut servir à départager ces incohérences.

Pas tout à fait. Wikipedia est très utile pour pas mal de ces 
incohérences. En l'occurrence on découvre que :

* Hongerford est grosso-modo inconnu au bataillon.

* Hungerford est une bourgade Anglaise qui est jumelée avec Ligueil, la 
  ville où ce trouve cette voie !
  https://fr.wikipedia.org/wiki/Hungerford

* Et la page anglaise de Ligueil confirme ce jumelage (mais rien sur la 
  page française).
  https://en.wikipedia.org/wiki/Ligueil

Donc, indépendamment de ce qui est écrit sur les panneaux, il y a de 
très fortes chances qu'Hungerford soit le nom correct.


-- 
Francois Gouget   http://fgouget.free.fr/
   Be careful of reading health books, you might die of a misprint.
 -- Mark Twain___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSRM-talk] Released OSRM 5.14.3

[Daniel Patterson]

Hi Mazen,

 Check out https://github.com/Project-OSRM/osrm-text-instructions which
knows how to generate sentences in various languages from the JSON data.

daniel

On Wed, Jan 3, 2018 at 11:30 AM, Mazen Mrad  wrote:

> Thanks a lot, now steps are returned, one more request, anyone have a
> javascript code to generate full route instructions  from the steps objects
>
> Mazen
>
> On Wed, Jan 3, 2018 at 7:42 PM, Daniel Patterson 
> wrote:
>
>> Hi Mazen,
>>
>>   Please go to http://project-osrm.org/ and click the "Documentation"
>> link on the main page.  This explains how to make requests, what parameters
>> you can supply, and how to interpret the response.
>>
>>   My guess is that you need to add `?steps=true` parameter to your
>> requests - turn-by-turn instructions are not included by default.  Also
>> consider the `overview=full` and `geometries=geojson` options to further
>> expand the response and simplify parsing.
>>
>> daniel
>>
>> On Wed, Jan 3, 2018 at 9:36 AM, Mazen Mrad  wrote:
>>
>>> So how to get the direction istructions.. please help
>>>
>>> On 3 Jan 2018 6:37 p.m., "Daniel Patterson"  wrote:
>>>
 Hi Mazen,

   You can ignore the hint object, it contains no user-visible data, and
 is not usable on the demoserver.

 daniel

 On Wed, Jan 3, 2018 at 8:08 AM, Mazen Mrad  wrote:

> Greetings;
>
> I am performing a route task using OSRM http api, it is working
> perfectly, but i need to extract the directions instructions and am not
> able to do it using javascript, the hint object in waypoint array is
> encrypted.
>
> Any idea please it is urgent.
>
> Thanks
>
> On Tue, Jan 2, 2018 at 8:18 PM, Michael Krasnyk <
> michael.kras...@gmail.com> wrote:
>
>> Hello,
>>
>> Happy New Year 2018!
>>
>> OSRM patch releases 5.14.2 and 5.14.3 add a new parameter
>> `max_radiuses_map_matching`, change default speed values in Belarus and
>> Ukraine and fix some bugs. The full list of changes is:
>>
>> # 5.14.3
>>  - Changes from 5.14.2:
>>- Bugfixes:
>>   - FIXED #4754: U-Turn penalties are applied to straight turns.
>>   - FIXED #4756: Removed too restrictive road name check in the
>> sliproad handler
>>   - FIXED #4731: Use correct weights for edge-based graph
>> duplicated via nodes.
>> - Profile:
>>   - CHANGED: added Belarus speed limits
>>   - CHANGED: set default urban speed in Ukraine to 50kmh
>>
>> # 5.14.2
>>  - Changes from 5.14.1:
>>- Bugfixes:
>>   - FIXED #4727: Erroring when a old .core file is present.
>>   - FIXED #4642: Update checks for EMPTY_NAMEID to check for
>> empty name strings
>>   - FIXED #4738: Fix potential segmentation fault
>> - Node.js Bindings:
>>   - ADDED: Exposed new `max_radiuses_map_matching` option from
>> `EngingConfig` options
>> - Tools:
>>   - ADDED: New osrm-routed `max_radiuses_map_matching` command
>> line flag to optionally set a maximum radius for map matching
>>
>> Regards,
>> Michael
>>
>>
>> ___
>> OSRM-talk mailing list
>> OSRM-talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>
>>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>

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


>>> ___
>>> OSRM-talk mailing list
>>> OSRM-talk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>>
>>>
>>
>> ___
>> OSRM-talk mailing list
>> OSRM-talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>
>>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSRM-talk] Released OSRM 5.14.3

[Mazen Mrad]

Thanks a lot, now steps are returned, one more request, anyone have a
javascript code to generate full route instructions  from the steps objects

Mazen

On Wed, Jan 3, 2018 at 7:42 PM, Daniel Patterson  wrote:

> Hi Mazen,
>
>   Please go to http://project-osrm.org/ and click the "Documentation"
> link on the main page.  This explains how to make requests, what parameters
> you can supply, and how to interpret the response.
>
>   My guess is that you need to add `?steps=true` parameter to your
> requests - turn-by-turn instructions are not included by default.  Also
> consider the `overview=full` and `geometries=geojson` options to further
> expand the response and simplify parsing.
>
> daniel
>
> On Wed, Jan 3, 2018 at 9:36 AM, Mazen Mrad  wrote:
>
>> So how to get the direction istructions.. please help
>>
>> On 3 Jan 2018 6:37 p.m., "Daniel Patterson"  wrote:
>>
>>> Hi Mazen,
>>>
>>>   You can ignore the hint object, it contains no user-visible data, and
>>> is not usable on the demoserver.
>>>
>>> daniel
>>>
>>> On Wed, Jan 3, 2018 at 8:08 AM, Mazen Mrad  wrote:
>>>
 Greetings;

 I am performing a route task using OSRM http api, it is working
 perfectly, but i need to extract the directions instructions and am not
 able to do it using javascript, the hint object in waypoint array is
 encrypted.

 Any idea please it is urgent.

 Thanks

 On Tue, Jan 2, 2018 at 8:18 PM, Michael Krasnyk <
 michael.kras...@gmail.com> wrote:

> Hello,
>
> Happy New Year 2018!
>
> OSRM patch releases 5.14.2 and 5.14.3 add a new parameter
> `max_radiuses_map_matching`, change default speed values in Belarus and
> Ukraine and fix some bugs. The full list of changes is:
>
> # 5.14.3
>  - Changes from 5.14.2:
>- Bugfixes:
>   - FIXED #4754: U-Turn penalties are applied to straight turns.
>   - FIXED #4756: Removed too restrictive road name check in the
> sliproad handler
>   - FIXED #4731: Use correct weights for edge-based graph
> duplicated via nodes.
> - Profile:
>   - CHANGED: added Belarus speed limits
>   - CHANGED: set default urban speed in Ukraine to 50kmh
>
> # 5.14.2
>  - Changes from 5.14.1:
>- Bugfixes:
>   - FIXED #4727: Erroring when a old .core file is present.
>   - FIXED #4642: Update checks for EMPTY_NAMEID to check for empty
> name strings
>   - FIXED #4738: Fix potential segmentation fault
> - Node.js Bindings:
>   - ADDED: Exposed new `max_radiuses_map_matching` option from
> `EngingConfig` options
> - Tools:
>   - ADDED: New osrm-routed `max_radiuses_map_matching` command
> line flag to optionally set a maximum radius for map matching
>
> Regards,
> Michael
>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>

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


>>>
>>> ___
>>> OSRM-talk mailing list
>>> OSRM-talk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>>
>>>
>> ___
>> OSRM-talk mailing list
>> OSRM-talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>
>>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-es] Cambio de logo para la comunidad OSM en España

[dazer]

Los cambios de Verdy_p de octubre no tienen absolutamente nada que ver con la
plantilla de país. Ni afecta a qué aparece en la página de España. No
necesita contar con ningún consenso para modificar lo que viene a ser un
repositiorio de logos. Se apuntó que es una modificación reciente como
contraargumento a que la bandera es el logo por defecto.

Como apunta dcapillae, la discusión es sobre la página del país, tras
decidir quitar el wikiproyect. La cuestión es si queremos usar ese logo que
está ahí disponible, u otros, para la página del país España.
Independientemente de la existencia de una comunidad de personas.

La confusión es precisamente la de mezclar comunidad con país. Ciertamente
la razón por la que este hilo tiene tantas respuestas. Es una cuestión de
armonizar con el resto del wiki, no de la identidad de la comunidad, o de
las gentes.



--
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: [OSM-talk-fr] Tagguer les cinémas "art & essai"

[osm . sanspourriel]

Nos messages ont dû se croiser car côté Wikipédia on a les mêmes références.
ref:FR:CNC          N°AUTO    12
~name     NOM ETABLISSEMENT    GEORGE V
devices? ECRANS    11
capacity ?              FAUTEUILS  1 666 (François capacity dans ce cas 
c'est bon où faudrait-il diviser par le nombre d'écrans ?)

(pour Osmose ?) CODE COMMUNE 75108
(pour Osmose ?)   COMMUNE    Paris 8me
cinema:art et cinema:art:FR et  ART ET ESSAI    NON

Pourquoi ces différences mineures ?
la clé globale c'est cinema et comme dit par Marc on la précise, donc 
cinema:art semble court et explicite.

Après on apporte une précision pour la France donc cinema:art:FR.
Art au singulier car on dit art film et art cinema.

Ça me semble plus logique donc plus simple.

Pour le brand, ce n'est pas une marque mais plutôt une affiliation et 
l'affiliation multiple est possible mais ni brand ni network ne le 
prévoient actuellement.

network:Europa_Cinemas=yes ?

Le 03/01/2018 à 09:53, Antoine Riche - antoine.ri...@ymail.com a écrit :
En anglais on parle de "arts cinema" 
(https://en.wikipedia.org/wiki/International_Confederation_of_Art_Cinemas), 
on pourrait utiliser arts=yes ou plus explicite arts_cinema=yes.


Il y a un numéro d'autorisation dans le fichier open data, on le met 
en ref:FR:CNC ?


De nombreuses salles Arts et Essai en Europe sont membres du réseau 
Europa Cinemas (http://www.europa-cinemas.org/), tant qu'à y être on 
pourrait les identifier avec brand=Europa Cinemas


Ce qui donne (pour les zélés) :
arts_cinema=yes (toute salle se réclamant Arts et Essai, avec ou sans 
label selon les pays)

ref:FR:CNC=
cinema:FR:art_essai=A|B|C|D|E  (salles classés par le CNC)
brand=Europa Cinemas (pour les salles du réseau)

La valeur no pour cinema:FR:art_essai ne me semble plus utile si on 
applique les autres tags, on aurait plutôt arts_cinema=no


Antoine.

Le 02/01/2018 à 23:24, marc marc a écrit :

Le 02. 01. 18 à 22:57,osm.sanspourr...@spamgourmet.com  a écrit :

Le 02/01/2018 à 21:10, George Kaplan -georgekaplan...@hotmail.fr  a écrit :

De façon similaire à school:FR, ça donne plutôt cinema:FR=art_essai .
Est-ce qu’il y a un terme du CNC pour les cinémas qui ne sont pas
« art et essai » ?


Oui, c'est dans la liste citée et ça s'appelle "NON";-).
Je propose simplement :
cinema:FR:art_essai=A|B|C|D|E|no

étant donné que chaque cinéma est susceptible de diffuser ce genre de
film, ne serrait-il pas intéressant d'essayer de trouver un nom de tag
anglais "parent" qui puisse s'appliquer "mondialement" sous la forme
cinema: =yes/no ?

avoir un tag commun permet un jour d'avoir un outil qui permet de
trouver un tel cinéma peu importe s'il se trouve à Roubais ou à Mons.

cela n’empêche pas d'avoir un tag :FR pour l'affinage de la
classification niveau français mais qui irait dans un sous-tag du tag
avec le mot anglais comme c'est la tradition dans osm.
par analogie, on utilise school:FR et non pas ecole:FR
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr




 
	Garanti sans virus. www.avast.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


___
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-latam] (no subject)

[Javier Sánchez Portero]

Hola

Me llamo Javier y llevo un tiempo contribuyendo al mapa principalmente en
las Islas Canarias.

Miguel cuenta conmigo si puedo ayudar. Los contenidos que sean comunes se
pueden trasladar a plantillas y cada comunidad puede crear sus páginas
incluyendo la parte común con la plantilla y a continuación el contenido
específico.

Cuando busque contactar con la comunidad hispanohablante en la Wiki no
encontré enlaces a esta lista y al grupo de Telegram

https://wiki.openstreetmap.org/wiki/ES:Wikiproyecto_Comunidad_hispana

La edito y actualizo.

Saludos a todos,
Javier Sánchez
___
talk-latam mailing list
talk-latam@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-latam

Re: [OSM-talk-fr] *** BULK *** Re: Contours des IRIS

[Philippe Verdy]

Note: ton expérimentation utilisait le fichier des IRIS de 2013, ce n'est
pas vraiment le dernier en date, et le fichier de 2016 contient tous les
départements y compris l'outremer (sauf encore Mayotte dont la couverture
cadastrale en cours est encore loin d'être aboutie alors que les
changements y sont importants avec la hausse rapide de sa population)
Il est possible que les shapes de 2016 soit déjà plus précis que ce qu'ils
étaient dans l'édition de 2013 (basées sur les données collectées en 2012):
entre temps il y a eu beaucoup de communes vectorisées et plein de SIG
communaux ou intercommunaux se sont montés et ont gagné en puissance et
précision.

Le 3 janvier 2018 à 17:13, Vincent de Château-Thierry  a
écrit :

>
> > De: "Philippe Verdy" 
> >
> > Je n'ai jamais parlé pas d'importation directe mais bien
> > d'intégration (comme tout ce qui se fait dans OSM de toute façon!)
> > Ce n'est pas parce que le GéoFLA était imprécis qu'on n'a pas
> > intégré les limites communales à l'aide d'une meilleure source (le
> > cadastre malgré qu'il n'était même pas vectorisé en grande partie)
> > en faisant les conflations nécessaires et qu'on a cherché à
> > cependant respecter le même découpage que l'INSEE (et on n'a pas
> > atendu non plus que l'INSEE se mette à jour quand les communes ont
> > changé on avait fait le travail avant).
>
> On est d'accord. Le souci aujourd'hui, c'est qu'à la différence de
> l'épisode des limites communales, on n'a pas de source géométrique correcte
> pour les IRIS. Même sur Paris où tu proposes de tester, les limites passent
> trop souvent entre 2 rues, sans qu'on sache si c'est volontaire ou si en
> fait la vraie limite est sur une des deux, et juste rendue imprécise par la
> simplification géométrique de Contours. Donc je ne vois pas l'intérêt d'un
> test avec une donnée géométrique si brouillonne. J'avais tenté une
> conflation OSM-Contours IRIS [1] mais j'ai du la limiter aux contours de
> communes tant les découpages infra-communaux étaient approximatifs. Je n'ai
> pas l'impression que la qualité géométrique a changé depuis.
> Pour moi tant qu'on n'a pas résolu la question d'une source géométrique
> fiable et de licence compatible, le sujet de l'intégration, en test ou au
> complet, ne se pose pas. Le jour venu, je suis d'accord avec toi sur
> l'ampleur modeste du projet et donc notre capacité à le maintenir. Le choix
> des tags en partant de boundary=statistic serait un bon départ à mon avis.
>
> vincent
>
> [1] : https://www.data.gouv.fr/fr/datasets/decoupage-iris-
> combine-aux-limites-communales-openstreetmap/
>
>
> ___
> 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] *** BULK *** Re: Contours des IRIS

[Philippe Verdy]

Paris n'est pas le meilleure exemple j'en ai donné d'autres. Mais tester
c'est faire une démo quelque part où ça peut donner des bons résultats. On
a vu Rennes se lancer dans ce travail (ce n'est pas la commune la plus
simple). Mais il peut y avoir d'autres initiatives ailleurs.

On peut commencer doucement pour ensuite voir ces données exploitées dans
certaines villes et pousser les autres à suivre et demander à travailler
avec l'INSEE sur des données plus précises. Cela peut aussi inciter à avoir
une meilleure vue citoyenne sur la façon dont les découpages électoraux
sont faits (et ont souvent été critiqué pour le manque complet de
transparence et des soupçons de clientélisme dans les élections).
Les grands partis politiques qui contrôlaient les élections avant sont à la
ramasse, et le changement massif de majorité devrait pousser la majorité
actuelle à ne pas être accusée des mêmes maux du passé (il n'y a pas qu'un
président, mais aussi une majorité nouvelle née qui pourrait ne pas aimer
se faire simplement traiter comme des moutons dociles): les initiatives
locales pourraient pousser à aller de l'avant, surtout si cela vient de la
société civile (nous en sommes) afin d'éviter que se creuse davantage
l'écart.

On sait que des arbitrages douloureux vont avoir lieu sur plain de services
publics et que les idées de nouvelles taxes ne vont pas être appréciées.
Les communes sont à la peine et se voient limiter leurs budgets.
L'influence de l'Etat est moins forte, la société civile peut prendre un
pied en s'impliquant directement. Même les gros partis vont se reformer et
se restructurer en faisant plus confiance à la société civile (c'est leur
seule façon de continuer à exister et rester audible). L'heure est à la
transparence et l'initiative locale. Les communes n'attendent plus grand
chose de l'Etat ou de ses agences comme l'INSEE. Mais on n'est pas là pour
casser l'INSEE qui existera encore mais aura ses missions moins dépendantes
de l'Etat et plus à l'écoute des besoins locaux et des initiatives locales.
L'Insee pourrait se mettre à notre écoute et on peut aussi les aider
puisque l'Insee a autant de mal que nous à trouver des terrains de
collaboration avec l'IGN. Ces deux agences vont changer de voilure et de
façon de fonctionner de façon verticale et centralisatrice. L'Europe nous
pousse aussi à être innovant et cherche également à regagner la confiance
citoyenne (surtout depuis le chambardement du brexit).

Bref il y a de la place pour les collectivités locales qui au passage
peuvent aussi faire des économies d'échelle et aller vers plus de
coopérations sur des solutions ouvertes. Dans certaines communes il y a
aura reconnaissance du travail des assos locales et comités de quartiers et
redessiner les contours de la ville. On peut être un soutien (et pas que
nous, les assos caritatives aussi sont à la peine avec le désengagement de
l'Etat, et cherchent donc des collaborations transversales, y compris
internationales, pour regrouper des moyens, des équipes, faire des
expérimentations ici et là et développer de nouvelles solutions: l'Etat
suivra parce qu'il n'a pas vraiment le choix et ne peut pas se couper
davantage des collectivités locales à qui il demande beaucoup et de plus en
plus sans leur donner les moyens).

Alors regardons d'un peu plus près certains territoires qu'on pourraient
analyser: un nouveau tag c'est expérimental, et on pourra l'enrichir
ensuite d'un système de qualification et de validation. Le travail n'est
pas compliqué à amorcer dans plein de petites villes de province, et
l'initiative de Rennes peut aussi donner des pistes pour les autres et
passer ensuite à plus grande échelle pour obtenir la précision qui nous
manque et que l'Insee ne nous communique pas encore. Si on arrivait déjà à
couvrir 25% des villes (dont celles découpées en moins de 5-6 IRIS et
quelques grandes comme Rennes, le reste suivra, y compris Paris aussi qui
voudra ne pas rester en recul sur le mouvement qu'on appelle "la ville
intelligente" prenant en compte un découpage fin des territoires et des
besoins et une mesure fine et plus dynamique adaptée à d'autres besoins que
ceux actuellement encore traités par l'Insee).


Le 3 janvier 2018 à 17:13, Vincent de Château-Thierry  a
écrit :

>
> > De: "Philippe Verdy" 
> >
> > Je n'ai jamais parlé pas d'importation directe mais bien
> > d'intégration (comme tout ce qui se fait dans OSM de toute façon!)
> > Ce n'est pas parce que le GéoFLA était imprécis qu'on n'a pas
> > intégré les limites communales à l'aide d'une meilleure source (le
> > cadastre malgré qu'il n'était même pas vectorisé en grande partie)
> > en faisant les conflations nécessaires et qu'on a cherché à
> > cependant respecter le même découpage que l'INSEE (et on n'a pas
> > atendu non plus que l'INSEE se mette à jour quand les communes ont
> > changé on avait fait le travail avant).
>
> On est d'accord. Le souci aujourd'hui, c'est qu'à la différence de
> l'épisode 

Re: [Talk-it] Confine italo-francese sul Monte Bianco

[mbranco2]

Ne avevamo parlato qui [1] .
Come racconta in quel thread Gian Navillod, finché i francesi non ritrovano
la loro copia del trattato tra il Re di Sardegna e Napoleone III (che hanno
"perso"...) , ci teniamo in OSM il doppio confine :-)

@Ivo (OT) : beh, in qualche modo bisogna pur mappare i ghiacciai (un altro
esempio che varia sono le zone paludose) : l'unica è aggiornare sovente.


[1]
http://gis.19327.n8.nabble.com/Cima-Monte-bianco-Gmaps-l-assegna-ai-francesi-td5710234.html#none

Il giorno 3 gennaio 2018 17:51, Alfredo Gattai 
ha scritto:

>
>>>
>>> Non so se ha senso tenere i doppi confini, ma sicuramente se qualcuno
>>> tenta di risolverli in favore di una delle due parti si avvierà una
>>> guerra di edit che credo sia inutile...
>>>
>>>
> +1 Per Carita'.
> Per la cronaca, Francia ed Italia non sono completamente daccordo neanche
> lui limiti acque territoriali.
> Lasciamo perdere
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-hr] luke i pravila za plovidbu u njima

[Michal Fabík]

On 22.12.2017 12:10, Janko Mihelić wrote:

Najbliže što sam našao je ovaj dokument:

https://narodne-novine.nn.hr/clanci/sluzbeni/2013_06_79_1640.html
i dopune:
https://narodne-novine.nn.hr/clanci/sluzbeni/2015_05_57_1123.html

Zanimljivi su Članak 9. i Članak 48. Ni u jednom ni u drugom nisam vidio 
spominjanje znakova ograničenja brzine. Pretpostavljam da su te znakove 
stavili zbog učestalog kršenja zakona, a zakon kaže da se od obale do 
150 metara od obale smije voziti ne više od 5 čvorova, a od 150 do 300 
metara ne više od 8 čvorova. Glisirati se smije samo dalje od 300 metara.


Ne bih to mapirao dok ne nađemo zakon koji obvezuje plovila da poštuju 
te znakove. Možda se spominje negdje, a ja nisam našao. Ako se ti 
znakovi stvarno po zakonu moraju poštovati, onda mislim da bi trebalo 
nacrtati površinu gdje je to maksimalna brzina, i onda na tu površinu 
staviti tagove area=yes + maxspeed=4 kn


Janko


Pozdrav,
izvinjavam se na kasnom odgovoru, imao sam puno posla u nekim drugim 
dijelovima mape:)


Nisam ni ja našao neki opšti propis, ali sam našao ovo, konkretno za 
Rijeku:


http://www.portauthority.hr/documents/pravilnik-rijeka-hr_v16.pdf

Vidio sam i veoma sličan dokument za Šibenik (mada u drugom formatu i 
pod malo drugačijim nazivom), tako da pretpostavljam da postoji tako 
nešto za svaku luku. Dokle je ovo obavezujuće, odnosno da li ovo ima 
status zakona, to već ne znam.


Ovdje se konkretno spominje dozvoljena brzina 5 čvorova za "sve brodove 
i brodice koji plove akvatorijem Luke" i VHF kanal 09, kao što piše na 
tabli na lukobranu.


Takođe, u dokumentu je definisana i "Luka", odnosno "lučko područje 
Lučke uprave Rijeka", koje bi valjda trebalo da bude obuhvaćeno u 
poligonu "Luka Rijeka", samo nisam siguran kako mapirati, s obzirom da 
se radi o kombinaciji kopnenih i vodenih područja.


Pozdrav,

--
Michal

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

Re: [Talk-es] Traducción de la plantilla Country y de OSM Streak

[Miguel Sevilla-Callejo]

En realidad en algún momento deberíamos de coordinarnos con nuestros 
colegas latinoamericanos para que los contenidos en español estén 
centralizados para los colaboradores a ambos lados del Atlántico.


Se hacen cosas de vez en cuando pero sería genial tener un grupo de 
trabajo común. Hay muchos temas que tratamos en la comunidad española 
que son igualmente trasladables a Latinoamérica: buenas prácticas, 
tutoriales, presentaciones...


Un saludo

Miguel


On 03/01/18 19:21, Javier Sánchez Portero wrote:

Gracias Miguel.

En su página no están esos enlaces. Me pondré en contacto con ellos.

http://wiki.openstreetmap.org/wiki/ES:Wikiproyecto_Comunidad_hispana

El 3 ene. 2018 17:45, "Miguel Sevilla-Callejo" > escribió:


Paso enlace de tu mensaje [0] en esta lista al grupo de Telegram
de Latinoamérica [1]

Tienen una lista de correos (copio también allí) pero es poco
activa [2]

Un saludo

[0]
https://lists.openstreetmap.org/pipermail/talk-es/2018-January/015622.html

[1] https://t.me/osmlatam
[2] https://lists.openstreetmap.org/listinfo/talk-latam


On 02/01/18 18:07, Javier Sánchez Portero wrote:

Hola

De cara a los miembros de la lista situados fuera de España,
comentar que está traducida al español la plantilla Country [1]
de la Wiki. Hasta ahora, esta plantilla se ha usado en ES:Costa
Rica [2] y, recientemente, en ES:España [3] y estaba disponible
sólo en inglés. Espero que al estar traducida pueda ser útil para
otros países hispanohablantes.

También puede interesar esta plantilla a las comunidades locales
para usarla en sus páginas. Si deseas traducir el texto a
cualquier otro idioma hazlo en la plantilla CountryLang [4].

Por otro lado, también está traducida la aplicación web OSM
Streak [5].

Saludos, Javier

[1] https://wiki.openstreetmap.org/wiki/Template:Country

[2] https://wiki.openstreetmap.org/wiki/WikiProject_Costa_Rica

[3] https://wiki.openstreetmap.org/wiki/ES:Espa%C3%B1a

[4] https://wiki.openstreetmap.org/wiki/Template:CountryLang

[5] https://wiki.openstreetmap.org/wiki/ES:OSM_Streak




___
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




___
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-latam] [Talk-es] Traducción de la plantilla Country y de OSM Streak

[Miguel Sevilla-Callejo]

En realidad en algún momento deberíamos de coordinarnos con nuestros 
colegas latinoamericanos para que los contenidos en español estén 
centralizados para los colaboradores a ambos lados del Atlántico.


Se hacen cosas de vez en cuando pero sería genial tener un grupo de 
trabajo común. Hay muchos temas que tratamos en la comunidad española 
que son igualmente trasladables a Latinoamérica: buenas prácticas, 
tutoriales, presentaciones...


Un saludo

Miguel


On 03/01/18 19:21, Javier Sánchez Portero wrote:

Gracias Miguel.

En su página no están esos enlaces. Me pondré en contacto con ellos.

http://wiki.openstreetmap.org/wiki/ES:Wikiproyecto_Comunidad_hispana

El 3 ene. 2018 17:45, "Miguel Sevilla-Callejo" > escribió:


Paso enlace de tu mensaje [0] en esta lista al grupo de Telegram
de Latinoamérica [1]

Tienen una lista de correos (copio también allí) pero es poco
activa [2]

Un saludo

[0]
https://lists.openstreetmap.org/pipermail/talk-es/2018-January/015622.html

[1] https://t.me/osmlatam
[2] https://lists.openstreetmap.org/listinfo/talk-latam


On 02/01/18 18:07, Javier Sánchez Portero wrote:

Hola

De cara a los miembros de la lista situados fuera de España,
comentar que está traducida al español la plantilla Country [1]
de la Wiki. Hasta ahora, esta plantilla se ha usado en ES:Costa
Rica [2] y, recientemente, en ES:España [3] y estaba disponible
sólo en inglés. Espero que al estar traducida pueda ser útil para
otros países hispanohablantes.

También puede interesar esta plantilla a las comunidades locales
para usarla en sus páginas. Si deseas traducir el texto a
cualquier otro idioma hazlo en la plantilla CountryLang [4].

Por otro lado, también está traducida la aplicación web OSM
Streak [5].

Saludos, Javier

[1] https://wiki.openstreetmap.org/wiki/Template:Country

[2] https://wiki.openstreetmap.org/wiki/WikiProject_Costa_Rica

[3] https://wiki.openstreetmap.org/wiki/ES:Espa%C3%B1a

[4] https://wiki.openstreetmap.org/wiki/Template:CountryLang

[5] https://wiki.openstreetmap.org/wiki/ES:OSM_Streak




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




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




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


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

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[Antoine Riche]

Sympa ce Mapcat en effet. Manque juste un truc : le © Les contributeurs 
OpenStreetMap à côté du © Wikipédia. Même en version Beta c'est dommage...


Le 03/01/2018 à 10:42, Christian Quest a écrit :
Rendu vectoriel... et mapcat est un très bel exemple de ce qu'on peut 
faire avec les données OSM + wikipédia.


Le 3 janvier 2018 à 10:40, Bruno > a écrit :


Le 03/01/2018 à 10:25, Marc Gemis a écrit :

Connaissez-vous https://www.mapcat.com ?
- OSM data
- clic gauche
- des noms en langue locale et Anglais.

m.

Je ne connaissais pas.
Pour le changement de langue et vu le choix important, j'imagine
qu'il n'y a pas un rendu par langage ? c'est quoi le mécanisme
technique ?





---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-GB] BT phoneboxes

[Brian Prangle]

Happy New Year everyone

BT are planning to remove thousands of phoneboxes, many of which we will
have mapped.I understand that for every two they remove they will be
installing one  InLink 

These street "pods" have free wifi, free calls, free device charging  and
an information tablet: all financed by the inbuilt advertising screens.

In London and Leeds the rollout has already started and the next city to
start is Birmingham

So how to tag this installation?  Has anyone mapped one yet?

The only online source for locations is based on Google Maps, so good for a
guide as to where to look but not suitable as a data source. I have a
contact in Business Development in BT and I have asked for a suitable source

Regards

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

Re: [Talk-es] Cambio de logo para la comunidad OSM en España

[Agustin Diez-Castillo]

+2 a que hay cosas más importantes que discutir, +1 a tus comentarios al logo 
ES y al borrador de logo. En este último punto, siento discrepar con tu idea 
inicial de que quedaría mal un perfil geográfico :-) Acabas de demostrar que 
puede quedar hasta bien. Dicho lo cual me sumo a tus comentarios iniciales y si 
hay que votar, voto por el que tiene ES, aunque me parece más bonito el 
borrador, es el más neutro, sin duda.

> On 3 Jan 2018, at 18:25, Miguel Sevilla-Callejo  wrote:
> 
> https://imgur.com/MR8M73Q 


smime.p7s
Description: S/MIME cryptographic signature
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Traducción de la plantilla Country y de OSM Streak

[Miguel Sevilla-Callejo]

Paso enlace de tu mensaje [0] en esta lista al grupo de Telegram de 
Latinoamérica [1]


Tienen una lista de correos (copio también allí) pero es poco activa [2]

Un saludo

[0] 
https://lists.openstreetmap.org/pipermail/talk-es/2018-January/015622.html

[1] https://t.me/osmlatam
[2] https://lists.openstreetmap.org/listinfo/talk-latam

On 02/01/18 18:07, Javier Sánchez Portero wrote:

Hola

De cara a los miembros de la lista situados fuera de España, comentar 
que está traducida al español la plantilla Country [1] de la Wiki. 
Hasta ahora, esta plantilla se ha usado en ES:Costa Rica [2] y, 
recientemente, en ES:España [3] y estaba disponible sólo en inglés. 
Espero que al estar traducida pueda ser útil para otros países 
hispanohablantes.


También puede interesar esta plantilla a las comunidades locales para 
usarla en sus páginas. Si deseas traducir el texto a cualquier otro 
idioma hazlo en la plantilla CountryLang [4].


Por otro lado, también está traducida la aplicación web OSM Streak [5].

Saludos, Javier

[1] https://wiki.openstreetmap.org/wiki/Template:Country 

[2] https://wiki.openstreetmap.org/wiki/WikiProject_Costa_Rica 

[3] https://wiki.openstreetmap.org/wiki/ES:Espa%C3%B1a 

[4] https://wiki.openstreetmap.org/wiki/Template:CountryLang 


[5] https://wiki.openstreetmap.org/wiki/ES:OSM_Streak



___
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: [OSRM-talk] Released OSRM 5.14.3

[Daniel Patterson]

Hi Mazen,

  Please go to http://project-osrm.org/ and click the "Documentation" link
on the main page.  This explains how to make requests, what parameters you
can supply, and how to interpret the response.

  My guess is that you need to add `?steps=true` parameter to your requests
- turn-by-turn instructions are not included by default.  Also consider the
`overview=full` and `geometries=geojson` options to further expand the
response and simplify parsing.

daniel

On Wed, Jan 3, 2018 at 9:36 AM, Mazen Mrad  wrote:

> So how to get the direction istructions.. please help
>
> On 3 Jan 2018 6:37 p.m., "Daniel Patterson"  wrote:
>
>> Hi Mazen,
>>
>>   You can ignore the hint object, it contains no user-visible data, and
>> is not usable on the demoserver.
>>
>> daniel
>>
>> On Wed, Jan 3, 2018 at 8:08 AM, Mazen Mrad  wrote:
>>
>>> Greetings;
>>>
>>> I am performing a route task using OSRM http api, it is working
>>> perfectly, but i need to extract the directions instructions and am not
>>> able to do it using javascript, the hint object in waypoint array is
>>> encrypted.
>>>
>>> Any idea please it is urgent.
>>>
>>> Thanks
>>>
>>> On Tue, Jan 2, 2018 at 8:18 PM, Michael Krasnyk <
>>> michael.kras...@gmail.com> wrote:
>>>
 Hello,

 Happy New Year 2018!

 OSRM patch releases 5.14.2 and 5.14.3 add a new parameter
 `max_radiuses_map_matching`, change default speed values in Belarus and
 Ukraine and fix some bugs. The full list of changes is:

 # 5.14.3
  - Changes from 5.14.2:
- Bugfixes:
   - FIXED #4754: U-Turn penalties are applied to straight turns.
   - FIXED #4756: Removed too restrictive road name check in the
 sliproad handler
   - FIXED #4731: Use correct weights for edge-based graph
 duplicated via nodes.
 - Profile:
   - CHANGED: added Belarus speed limits
   - CHANGED: set default urban speed in Ukraine to 50kmh

 # 5.14.2
  - Changes from 5.14.1:
- Bugfixes:
   - FIXED #4727: Erroring when a old .core file is present.
   - FIXED #4642: Update checks for EMPTY_NAMEID to check for empty
 name strings
   - FIXED #4738: Fix potential segmentation fault
 - Node.js Bindings:
   - ADDED: Exposed new `max_radiuses_map_matching` option from
 `EngingConfig` options
 - Tools:
   - ADDED: New osrm-routed `max_radiuses_map_matching` command line
 flag to optionally set a maximum radius for map matching

 Regards,
 Michael


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


>>>
>>> ___
>>> OSRM-talk mailing list
>>> OSRM-talk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>>
>>>
>>
>> ___
>> OSRM-talk mailing list
>> OSRM-talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>
>>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-es] sobre el tema de ser o no ser comunidad

[yo paseopor]

Me parece una estupenda opción, tanto esa, como la del logo, el cual  me
gusta más que los tres anteriores. Contad conmigo por supuesto para salir
en ese staff, ni que sea arreglando estaciones de transporte público o
toquiteando señales ;)
Salut i wiki
yopaseopor

2018-01-03 17:21 GMT+01:00 Miguel Sevilla-Callejo :

> Hola,
>
> Con el tema de la edición en la Wiki y las intereacciones que ha habido en
> la página del proyecto, además de agradecer el magnífico trabajo que está
> liderando Daniel, me ha surgido la idea de poder contrarrestar la acción
> unilateral que ha tenido el usuario Verdy_p [1].
>
> Por lo visto como no somos "local chapter" de OSM no nos reconoce como
> comunidad, y es por ello que se me ha ocurrido que en la propia wiki, en el
> proyecto España, podríamos incluir de manera explícita quiénes somos y qué
> hacemos. Todo esto dejando a un lado que deberíamos de una vez por todas
> reactivar la asociación pero para esto ya volveré a la carga más adelante.
>
> La idea es que hubiera un apartado claro sobre la comunidad, que podría
> enlazar además con la asociación, y ahí pusiéramos esta lista de correos
> como la herramienta básica de la comunidad además de añadir los usuarios
> más activos de la comunidad.
>
> Y es que opino que somos un buen puñado de usuarios que de manera
> consensuada estamos trabajando para el proyecto y que a pesar de la
> ausencia del "capítulo local" incluso de una asociación activa, podemos
> interpelar al cualquier advenedizo que se le ocurra editar/modificar algo
> unilateralmente y contra el consenso de la comunidad.
>
> Se me ocurre que podemos tirar de aquella lista de personas que ya nos
> manifestamos para tirar adelante con la asociación e incluso asignarnos
> papeles dentro de las tareas de la comunidad (wiki, Twitter, grupos de
> mensajería instantánea, proyectos específicos...).
>
> Lo que propongo es algo informal pero creo que puede ser útil para dejarlo
> reflejado en la wiki.
>
> ¿Qué os parece?
>
> Un saludo y, se me olvidaba, FELIZ 2018 a todos
>
> Miguel
>
> [1] ver comentarios en https://wiki.openstreetmap.
> org/wiki/ES_talk:Espa%C3%B1a#A.C3.B1adir_plantilla_de_lugar
>
> --
> *Miguel Sevilla-Callejo*
> Doctor en Geografía
>
> ___
> 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: [OSRM-talk] Released OSRM 5.14.3

[Mazen Mrad]

So how to get the direction istructions.. please help

On 3 Jan 2018 6:37 p.m., "Daniel Patterson"  wrote:

> Hi Mazen,
>
>   You can ignore the hint object, it contains no user-visible data, and is
> not usable on the demoserver.
>
> daniel
>
> On Wed, Jan 3, 2018 at 8:08 AM, Mazen Mrad  wrote:
>
>> Greetings;
>>
>> I am performing a route task using OSRM http api, it is working
>> perfectly, but i need to extract the directions instructions and am not
>> able to do it using javascript, the hint object in waypoint array is
>> encrypted.
>>
>> Any idea please it is urgent.
>>
>> Thanks
>>
>> On Tue, Jan 2, 2018 at 8:18 PM, Michael Krasnyk <
>> michael.kras...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> Happy New Year 2018!
>>>
>>> OSRM patch releases 5.14.2 and 5.14.3 add a new parameter
>>> `max_radiuses_map_matching`, change default speed values in Belarus and
>>> Ukraine and fix some bugs. The full list of changes is:
>>>
>>> # 5.14.3
>>>  - Changes from 5.14.2:
>>>- Bugfixes:
>>>   - FIXED #4754: U-Turn penalties are applied to straight turns.
>>>   - FIXED #4756: Removed too restrictive road name check in the
>>> sliproad handler
>>>   - FIXED #4731: Use correct weights for edge-based graph duplicated
>>> via nodes.
>>> - Profile:
>>>   - CHANGED: added Belarus speed limits
>>>   - CHANGED: set default urban speed in Ukraine to 50kmh
>>>
>>> # 5.14.2
>>>  - Changes from 5.14.1:
>>>- Bugfixes:
>>>   - FIXED #4727: Erroring when a old .core file is present.
>>>   - FIXED #4642: Update checks for EMPTY_NAMEID to check for empty
>>> name strings
>>>   - FIXED #4738: Fix potential segmentation fault
>>> - Node.js Bindings:
>>>   - ADDED: Exposed new `max_radiuses_map_matching` option from
>>> `EngingConfig` options
>>> - Tools:
>>>   - ADDED: New osrm-routed `max_radiuses_map_matching` command line
>>> flag to optionally set a maximum radius for map matching
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>> ___
>>> OSRM-talk mailing list
>>> OSRM-talk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>>
>>>
>>
>> ___
>> OSRM-talk mailing list
>> OSRM-talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>
>>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[Samy Mezani]

Il y a aussi https://openmaptiles.org/ qui affiche les noms dans pas mal 
de langues.


Le lien est plutôt https://openmaptiles.org/languages/fr/

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

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[Samy Mezani]

Bonjour,

Le 03/01/2018 à 09:55, Bruno a écrit :
La carte est affichée dans la langue du pays par défaut, si je regarde 
la Russie ou la Pologne , et bien c'est inutilisable (pour moi)




Il y a aussi https://openmaptiles.org/ qui affiche les noms dans pas mal 
de langues.


Samy

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

Re: [Talk-es] Cambio de logo para la comunidad OSM en España

[dcapillae]

Insisto en que no estamos cambiando el logo de la comunidad OSM española,
aunque este hilo lleve ese nombre y provoque cierta confusión. Lo que se ha
propuesto es una votación para elegir la imagen que nos gustaría que
apareciera como «bandera» en la plantilla «Country», en principio, una
cuestión menor. La plantilla «Country» es la que estamos usando para el
nuevo diseño de la página del wiki:
https://wiki.openstreetmap.org/wiki/Template:Country

El logo de la comunidad OSM española puede seguir siendo el mismo y lo
podemos incluir también en la página. Personalmente no tengo ningún interés
en cambiarlo. Tampoco en conservarlo, me es indiferente. Ahora bien,
respecto a la bandera, me parecería un error no utilizarla en la página de
España, por los motivos que ya se han expuesto.

Ni le quito ni le doy importancia. Ciertamente hay muchas otras cosas en que
pensar. Inicialmente yo tampoco le daba mayor importancia, pero, visto lo
visto, importante debe ser cuando tanta gente opina y tiene interés en que
conozcamos su opinión. Me parece un acierto que Javier haya traído esta
cuestión menor a la lista.



-
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: [OSM-talk-fr] Question sur le rendu standard !

[Christian Quest]

C'est visiblement un bug de mapnik et/ou de postgis pour calculer une
position au libellé sur le polygone.

Ce n'est pas lié directement à la feuille de style des rendus, mais aux
libraires sous-jacentes...

postgis propose 2 fonctions : ST_Centroid et ST_PointOnSurface

ST_Centroid ne garantit pas que le point est dans le polygone, et
ST_PointOnSurface garantit que le point est dans le polygone, mais pas
forcément là où naturellement on le mettrait

Un nouvel algo est apparu il y a peu pour calculer une position plus
naturelle, mais il n'est pas encore intégré à postgis ou mapnik à ce que je
sache.



Le 3 janvier 2018 à 16:50, althio  a écrit :

> >> Où fait-on remonter ce type de problème (si c'est bien un problème ?) ?
> >
> > ici https://github.com/gravitystorm/openstreetmap-carto/issues
> > et là https://github.com/cquest/osmfr-cartocss/issues
>
> En fait, cela doit déjà être connu :
> https://github.com/gravitystorm/openstreetmap-carto/issues/2428
> https://github.com/gravitystorm/openstreetmap-carto/issues/2511
> https://github.com/gravitystorm/openstreetmap-carto/issues/1465
>
> et voire "au-dessus", améliorations en cours dans les dernières
> versions de mapnik
> https://github.com/mapnik/mapnik/issues/3550
> https://github.com/mapnik/mapnik/issues/3558
> https://github.com/mapnik/mapnik/pull/3771
> https://github.com/mapnik/mapnik/pull/3811
>
> ___
> 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: [Talk-it] Confine italo-francese sul Monte Bianco

[Alfredo Gattai]

>
>
>>
>> Non so se ha senso tenere i doppi confini, ma sicuramente se qualcuno
>> tenta di risolverli in favore di una delle due parti si avvierà una
>> guerra di edit che credo sia inutile...
>>
>>
+1 Per Carita'.
Per la cronaca, Francia ed Italia non sono completamente daccordo neanche
lui limiti acque territoriali.
Lasciamo perdere
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] routing.openstreetmap.de

[michael spreng]

Hallo Jakob

On 31/12/17 14:29, Jakob Mühldorfer wrote:
> 
> Eine Frage zu diesem Teil:
> 
>> mit OSRM — mit Auto-, Fussgänger- und Bike-Profil
> Dies sind die standard Profile, unverändert von OSRM übernommen?
> 

Ist schon etwas an die OSRM profile angelehnt, aber doch recht anders.
Bis ich die Dokumentation fertig habe, schaut mal
https://github.com/sosm/cbf-routing-profiles an: car, foot-city und
bike-city
Die wurden ursprünglich mal von Sarah Hoffmann gemacht.

Grüsse
Michael

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

Re: [Talk-it] Confine italo-francese sul Monte Bianco

[Dario Crespi]

Grazie!

Il giorno 3 gennaio 2018 17:29, Luca 'remix_tj' Lorenzetto <
lorenzetto.l...@gmail.com> ha scritto:

> 2018-01-03 17:26 GMT+01:00 Ivo Reano :
> > Guardando la mappa (in modalità modifica) si può vedere che in realtà si
> > tratta del "piccolo territorio conteso".
>
> Giusto per completare le info:
>
> https://it.wikipedia.org/wiki/Storia_della_frontiera_sul_Monte_Bianco
>
> Non so se ha senso tenere i doppi confini, ma sicuramente se qualcuno
> tenta di risolverli in favore di una delle due parti si avvierà una
> guerra di edit che credo sia inutile...
>
> Luca
>
> --
> "E' assurdo impiegare gli uomini di intelligenza eccellente per fare
> calcoli che potrebbero essere affidati a chiunque se si usassero delle
> macchine"
> Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716)
>
> "Internet è la più grande biblioteca del mondo.
> Ma il problema è che i libri sono tutti sparsi sul pavimento"
> John Allen Paulos, Matematico (1945-vivente)
>
> Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , <
> lorenzetto.l...@gmail.com>
>
> ___
> 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: [OSRM-talk] Released OSRM 5.14.3

[Daniel Patterson]

Hi Mazen,

  You can ignore the hint object, it contains no user-visible data, and is
not usable on the demoserver.

daniel

On Wed, Jan 3, 2018 at 8:08 AM, Mazen Mrad  wrote:

> Greetings;
>
> I am performing a route task using OSRM http api, it is working perfectly,
> but i need to extract the directions instructions and am not able to do it
> using javascript, the hint object in waypoint array is encrypted.
>
> Any idea please it is urgent.
>
> Thanks
>
> On Tue, Jan 2, 2018 at 8:18 PM, Michael Krasnyk  > wrote:
>
>> Hello,
>>
>> Happy New Year 2018!
>>
>> OSRM patch releases 5.14.2 and 5.14.3 add a new parameter
>> `max_radiuses_map_matching`, change default speed values in Belarus and
>> Ukraine and fix some bugs. The full list of changes is:
>>
>> # 5.14.3
>>  - Changes from 5.14.2:
>>- Bugfixes:
>>   - FIXED #4754: U-Turn penalties are applied to straight turns.
>>   - FIXED #4756: Removed too restrictive road name check in the
>> sliproad handler
>>   - FIXED #4731: Use correct weights for edge-based graph duplicated
>> via nodes.
>> - Profile:
>>   - CHANGED: added Belarus speed limits
>>   - CHANGED: set default urban speed in Ukraine to 50kmh
>>
>> # 5.14.2
>>  - Changes from 5.14.1:
>>- Bugfixes:
>>   - FIXED #4727: Erroring when a old .core file is present.
>>   - FIXED #4642: Update checks for EMPTY_NAMEID to check for empty
>> name strings
>>   - FIXED #4738: Fix potential segmentation fault
>> - Node.js Bindings:
>>   - ADDED: Exposed new `max_radiuses_map_matching` option from
>> `EngingConfig` options
>> - Tools:
>>   - ADDED: New osrm-routed `max_radiuses_map_matching` command line
>> flag to optionally set a maximum radius for map matching
>>
>> Regards,
>> Michael
>>
>>
>> ___
>> OSRM-talk mailing list
>> OSRM-talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>
>>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-it] Confine italo-francese sul Monte Bianco

[Luca 'remix_tj' Lorenzetto]

2018-01-03 17:26 GMT+01:00 Ivo Reano :
> Guardando la mappa (in modalità modifica) si può vedere che in realtà si
> tratta del "piccolo territorio conteso".

Giusto per completare le info:

https://it.wikipedia.org/wiki/Storia_della_frontiera_sul_Monte_Bianco

Non so se ha senso tenere i doppi confini, ma sicuramente se qualcuno
tenta di risolverli in favore di una delle due parti si avvierà una
guerra di edit che credo sia inutile...

Luca

-- 
"E' assurdo impiegare gli uomini di intelligenza eccellente per fare
calcoli che potrebbero essere affidati a chiunque se si usassero delle
macchine"
Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716)

"Internet è la più grande biblioteca del mondo.
Ma il problema è che i libri sono tutti sparsi sul pavimento"
John Allen Paulos, Matematico (1945-vivente)

Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , 

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

Re: [Talk-it] Confine italo-francese sul Monte Bianco

[Ivo Reano]

Guardando la mappa (in modalità modifica) si può vedere che in realtà si
tratta del "piccolo territorio conteso".
La mappatura mi sembra corretta, è indicata anche il wiki Q14981 (che sono
andato a leggere per capire cos'era!)
OT: ma le zone di ghiacciaio, di per se effimere anche senza considerare il
cambiamento climatico antropico, come posso essere così precise?

Il giorno 3 gennaio 2018 17:06, Dario Crespi  ha
scritto:

> Ciao,
>
> casualmente ho visto che il confine tra Italia e Francia nei pressi del
> Monte Bianco ha qualche problema: http://www.openstreetmap.org/#map=14/45.
> 8347/6.8516
>
> Si può  sistemare?
>
> Dario
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] routing.openstreetmap.de

[michael spreng]

On 31/12/17 15:05, Toni Erdmann wrote:
> Am 30.12.2017 um 00:45 schrieb michael spreng:
>> Hallo
>>
>> Unter https://routing.openstreetmap.de/ gibt es nun weltweites Routing
>> mit OSRM — mit Auto-, Fussgänger- und Bike-Profil. Die Server sind von
>> FOSSGIS gesponsert und wurden von mir in den letzten paar Wochen
>> eingerichtet. Der eine Server rechnet basierend auf dem jeweils
>> aktuellen OSM-planet die Graphen aus, während der andere die Daten
>> ausliefert. Der Update-Zyklus ist im Moment etwa ein Tag. Probiert es
>> doch mal aus.
>>
>> Beste Grüsse
>> Michael
> 
> Danke Michael,
> 
> sieht gut aus und gefällt mir.
> 
> Ausgerechnet meine erste Route war sehr komisch.
> 
> 'Bike'
> 
> von 'Rosenheimer Landstraße 44; Ottobrunn, Landkreis München, Upper
> Bavaria, Bavaria, 85521, Germany'
> 
> nach 'A2J7D9, Avenue du Général de Gaulle, Pen ar Ru, Tachen An
> Hospital, Lannion, Côtes-d'Armor, Brittany, Metropolitan France, 22300,
> France'
> 
> aber, ja mei, warum net.
> 
> Gibt es die Möglichkeit einen "Permalink" zu generieren, den man
> "teilen" kann?
> 
> Mit "refresh" im FF kommt dann das Folgende in die Adresszeile:
> 
> https://routing.openstreetmap.de/?z=6=48.290503%2C11.403809=48.065289%2C11.660743=48.728157%2C-3.460500=en=0=1
> 
>

Hallo

Ah schon wieder dieser Fähren Bug. Ich hoffe, dass ich den bald
beseitigt habe.

Ja der Link in der Adressleiste ist ein Permalink.

Grüsse
Michael

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

Re: [Talk-es] Cambio de logo para la comunidad OSM en España

[Miguel Sevilla-Callejo]

Yo revertiría lo que hizo unilateralmente Verdy_p para dejarlo como estaba
pues creo que no está legitimado para cambiar nada sin contar con la
comunidad y daría algo más de plazo para manifestarnos.

--
*Miguel Sevilla-Callejo*
Doctor en Geografía

2018-01-03 17:06 GMT+01:00 Javier Sánchez Portero :

> ¿Os parece bien poner un plazo para cerrar los votos? Por ejemplo hasta el
> domingo 7.
>
> Javier
>
> El 3 de enero de 2018, 15:41, Miguel Sevilla-Callejo  > escribió:
>
>> Hola,
>>
>> Por fin tengo un momento a para opinar sobre el asunto.
>>
>> Hace tiempo, creo que ya hace un par de años, que al abrir el grupo de
>> Telegram e ir a actualizar algún aspecto de la Wiki me decidí junto con
>> Oscar Zorrilla a pasar a vectorial un logo que alguien había hecho
>> previamente añadiendo un "es" al logo de OSM.
>>
>> Entonces pensamos sobre la conveniencia de tener uno u otro logo, como se
>> está planteando en este momento y nos decidimos a poner el "ES" en
>> mayúsculas, que es, junto con el "ESP" y el "724" el código ISO de España y
>> en aquel momento le pareció bien a todo el mundo.
>>
>> Mi parecer sigue siendo el mismo que el que tuve en su día, el que he
>> expresado en otras vías, este logotipo de la comunidad española es el más
>> adecuado puesto que es el políticamente más neutro y puesto que el perfíl
>> geográfico del territorio español creo que no quedará bien (pues habrá que
>> incluir los los archipiélagos y las ciudades autónomas africanas).
>>
>> Como ya se ha comentado en los anteriores mensajes tenemos que buscar
>> soluciones que unan pues somos comunidad y desafortunadamente en España el
>> tema de la bandera es uno de ellos.
>>
>> Dicho todo lo anterior creo que tenemos temas mucho más relevantes y
>> tareas abiertas más importantes que discutir que si ponemos la bandera o no
>> en un logo.
>>
>> Sin ir más lejos, el tema de la asociación OSM es sigue encallado, lo que
>> nos podría dar opción a constituirnos como "local chapter"  y no vendría
>> cualquiera a decirnos qué hemos de hacer o a no reconocernos como comunidad
>> (algo, por otro lado que me parece intolerable por su parte).
>>
>> Un saludo
>>
>> Miguel
>>
>>
>> --
>> *Miguel Sevilla-Callejo*
>> Doctor en Geografía
>>
>> 2018-01-03 14:10 GMT+01:00 Javier Sánchez Portero :
>>
>>> Un dato en serio: El logo se está visualizando ahora mismo a 82x80
>>> píxeles y creo que debería tener siempre un tamaño algo menor que el de OSM
>>> (160x160). Eso no da para muchas filigranas.
>>>
>>> Y otro en broma: No estoy de acuerdo con usar el toro, prefiero rescatar
>>> la gitanilla ahora que han desaparecido los televisores de tubo.
>>>
>>> El 3 de enero de 2018, 11:49, dazer  escribió:
>>>
 Tiene el significado que quiera cada uno darle.
 Los logos no se supone que unan. Se supone que representan o
 identifican.

 En este caso identifica a un país; no a una comunidad de personas ni a
 un
 "pueblo". OSM representa realidades y conceptos. No sentimientos
 nacionales.
 La bandera es un concepto y una realidad identificable.

 La página de España, creo, no es para los españoles y sus
 sensibilidades,
 sino para coordinar los trabajos en España. Y eso implica que se pueda
 unir
 gente que no es de España; me parecería adecuado recibirles en un sitio
 que
 sea familar.
 Me parecería un error masivo no usar la bandera, independientemente de
 que a
 mi me gustase otro encaje territorial e institucional. Error porque la
 bandera es fácilmente reconocible e identificable dentro y, sobretodo,
 fuera
 de las fronteras. Es el símbolo que une con el resto del mundo.

 La opción de usar la figura del territorio (más Canarias, Baleares,
 ciudades
 autónomas, y plazas de soberanía menores) siempre se me ha antojado
 cutre:
 porque el territorio reconocible es la península (junto a Portugal), no
 la
 figura del país. Y peca de que en formatos pequeños, los territorios de
 la
 costa Africana no se ven (y merecen tanta representación como cualquier
 otro).

 Y ya medio jocoso, medio en serio: ya que otros países adoptan figuras
 folklóricas, estaría bien poner un toro de Osborne.



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

[Talk-es] sobre el tema de ser o no ser comunidad

[Miguel Sevilla-Callejo]

Hola,

Con el tema de la edición en la Wiki y las intereacciones que ha habido en
la página del proyecto, además de agradecer el magnífico trabajo que está
liderando Daniel, me ha surgido la idea de poder contrarrestar la acción
unilateral que ha tenido el usuario Verdy_p [1].

Por lo visto como no somos "local chapter" de OSM no nos reconoce como
comunidad, y es por ello que se me ha ocurrido que en la propia wiki, en el
proyecto España, podríamos incluir de manera explícita quiénes somos y qué
hacemos. Todo esto dejando a un lado que deberíamos de una vez por todas
reactivar la asociación pero para esto ya volveré a la carga más adelante.

La idea es que hubiera un apartado claro sobre la comunidad, que podría
enlazar además con la asociación, y ahí pusiéramos esta lista de correos
como la herramienta básica de la comunidad además de añadir los usuarios
más activos de la comunidad.

Y es que opino que somos un buen puñado de usuarios que de manera
consensuada estamos trabajando para el proyecto y que a pesar de la
ausencia del "capítulo local" incluso de una asociación activa, podemos
interpelar al cualquier advenedizo que se le ocurra editar/modificar algo
unilateralmente y contra el consenso de la comunidad.

Se me ocurre que podemos tirar de aquella lista de personas que ya nos
manifestamos para tirar adelante con la asociación e incluso asignarnos
papeles dentro de las tareas de la comunidad (wiki, Twitter, grupos de
mensajería instantánea, proyectos específicos...).

Lo que propongo es algo informal pero creo que puede ser útil para dejarlo
reflejado en la wiki.

¿Qué os parece?

Un saludo y, se me olvidaba, FELIZ 2018 a todos

Miguel

[1] ver comentarios en
https://wiki.openstreetmap.org/wiki/ES_talk:Espa%C3%B1a#A.C3.B1adir_plantilla_de_lugar

--
*Miguel Sevilla-Callejo*
Doctor en Geografía
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Contours des IRIS

[marc marc]

Le 03. 01. 18 à 16:42, Philippe Verdy a écrit :

> Ce n'est pas si gros que ça.

Il me semble erroné de parler d'intégration.
On peux pas dire à la fois qu'il y en a des milliers et que tu vas les 
intégrer seul à la main, on parle donc bien d'un import qui devra 
utiliser au maximum les objets actuels.

J'aimerai connaître :
- l'outil que tu vas utiliser pour rapprocher les limites libre 
imprécise de l'insee des frontières supposée exacte d'osm
- sur quelle base vas-tu décider où est le tracé exact entre 2 zone iris 
pour la partie du tracé qui ne suis pas une limite existante, par 
exemple lorsqu'il est entre 2 rues.
- un exemple de fichier .osm que tu veux importer sur par exemple une 
petite commune ayant 2 ou 3 iris.

> Pour le suivi des mises à jour on pourra encore utiliser les données INSEE

concrètement, comment cela se passe ?
quelle fréquence de changement ?
comment est publiée l'info de modif de tracé ?
l'ancien tracé est supprimé et un nouveau tracé avec un nouvel id voit 
le jour ?
ou un tracé peux être modifié et conserver le même id ?
quel outil qa pour suivre leur validité ? tu écris une analyse osmose ?

> Quel tag : boundary=statistic ?
+ ref:iris (admin_type et border_type ne conviennent pas selon moi)
sur la relation uniquement pour ne pas polluer des chemins avec des 
excès de tag redondant (d'autant + que tu dis que la majorités de ces 
chemins seront ceux des limites existantes)

Ceci dit, je pense qu'avant de vouloir faire des stats au niveau 
infra-communal pour comparer l'égalité des citoyens face aux infras 
publique (sic !), il faudrait avoir ces infras dans osm. quand on voit 
le nombre d'écoles manquantes, ce serrait pas un luxe de progresser sur 
ce point.
sinon la seule chose qu'on aura, c'est une surcouche qui affiche le 
contour dans iris sans aucune autre plus-value que son affichage.
Dans ce cas, un simple layer ou un umap fait tout aussi bien.

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

Re: [OSM-talk-fr] *** BULK *** Re: Contours des IRIS

[Vincent de Château-Thierry]

> De: "Philippe Verdy" 
> 
> Je n'ai jamais parlé pas d'importation directe mais bien
> d'intégration (comme tout ce qui se fait dans OSM de toute façon!)
> Ce n'est pas parce que le GéoFLA était imprécis qu'on n'a pas
> intégré les limites communales à l'aide d'une meilleure source (le
> cadastre malgré qu'il n'était même pas vectorisé en grande partie)
> en faisant les conflations nécessaires et qu'on a cherché à
> cependant respecter le même découpage que l'INSEE (et on n'a pas
> atendu non plus que l'INSEE se mette à jour quand les communes ont
> changé on avait fait le travail avant).

On est d'accord. Le souci aujourd'hui, c'est qu'à la différence de l'épisode 
des limites communales, on n'a pas de source géométrique correcte pour les 
IRIS. Même sur Paris où tu proposes de tester, les limites passent trop souvent 
entre 2 rues, sans qu'on sache si c'est volontaire ou si en fait la vraie 
limite est sur une des deux, et juste rendue imprécise par la simplification 
géométrique de Contours. Donc je ne vois pas l'intérêt d'un test avec une 
donnée géométrique si brouillonne. J'avais tenté une conflation OSM-Contours 
IRIS [1] mais j'ai du la limiter aux contours de communes tant les découpages 
infra-communaux étaient approximatifs. Je n'ai pas l'impression que la qualité 
géométrique a changé depuis.
Pour moi tant qu'on n'a pas résolu la question d'une source géométrique fiable 
et de licence compatible, le sujet de l'intégration, en test ou au complet, ne 
se pose pas. Le jour venu, je suis d'accord avec toi sur l'ampleur modeste du 
projet et donc notre capacité à le maintenir. Le choix des tags en partant de 
boundary=statistic serait un bon départ à mon avis.

vincent

[1] : 
https://www.data.gouv.fr/fr/datasets/decoupage-iris-combine-aux-limites-communales-openstreetmap/


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

Re: [OSRM-talk] Released OSRM 5.14.3

[Mazen Mrad]

Greetings;

I am performing a route task using OSRM http api, it is working perfectly,
but i need to extract the directions instructions and am not able to do it
using javascript, the hint object in waypoint array is encrypted.

Any idea please it is urgent.

Thanks

On Tue, Jan 2, 2018 at 8:18 PM, Michael Krasnyk 
wrote:

> Hello,
>
> Happy New Year 2018!
>
> OSRM patch releases 5.14.2 and 5.14.3 add a new parameter
> `max_radiuses_map_matching`, change default speed values in Belarus and
> Ukraine and fix some bugs. The full list of changes is:
>
> # 5.14.3
>  - Changes from 5.14.2:
>- Bugfixes:
>   - FIXED #4754: U-Turn penalties are applied to straight turns.
>   - FIXED #4756: Removed too restrictive road name check in the
> sliproad handler
>   - FIXED #4731: Use correct weights for edge-based graph duplicated
> via nodes.
> - Profile:
>   - CHANGED: added Belarus speed limits
>   - CHANGED: set default urban speed in Ukraine to 50kmh
>
> # 5.14.2
>  - Changes from 5.14.1:
>- Bugfixes:
>   - FIXED #4727: Erroring when a old .core file is present.
>   - FIXED #4642: Update checks for EMPTY_NAMEID to check for empty
> name strings
>   - FIXED #4738: Fix potential segmentation fault
> - Node.js Bindings:
>   - ADDED: Exposed new `max_radiuses_map_matching` option from
> `EngingConfig` options
> - Tools:
>   - ADDED: New osrm-routed `max_radiuses_map_matching` command line
> flag to optionally set a maximum radius for map matching
>
> Regards,
> Michael
>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-es] Cambio de logo para la comunidad OSM en España

[Javier Sánchez Portero]

¿Os parece bien poner un plazo para cerrar los votos? Por ejemplo hasta el
domingo 7.

Javier

El 3 de enero de 2018, 15:41, Miguel Sevilla-Callejo 
escribió:

> Hola,
>
> Por fin tengo un momento a para opinar sobre el asunto.
>
> Hace tiempo, creo que ya hace un par de años, que al abrir el grupo de
> Telegram e ir a actualizar algún aspecto de la Wiki me decidí junto con
> Oscar Zorrilla a pasar a vectorial un logo que alguien había hecho
> previamente añadiendo un "es" al logo de OSM.
>
> Entonces pensamos sobre la conveniencia de tener uno u otro logo, como se
> está planteando en este momento y nos decidimos a poner el "ES" en
> mayúsculas, que es, junto con el "ESP" y el "724" el código ISO de España y
> en aquel momento le pareció bien a todo el mundo.
>
> Mi parecer sigue siendo el mismo que el que tuve en su día, el que he
> expresado en otras vías, este logotipo de la comunidad española es el más
> adecuado puesto que es el políticamente más neutro y puesto que el perfíl
> geográfico del territorio español creo que no quedará bien (pues habrá que
> incluir los los archipiélagos y las ciudades autónomas africanas).
>
> Como ya se ha comentado en los anteriores mensajes tenemos que buscar
> soluciones que unan pues somos comunidad y desafortunadamente en España el
> tema de la bandera es uno de ellos.
>
> Dicho todo lo anterior creo que tenemos temas mucho más relevantes y
> tareas abiertas más importantes que discutir que si ponemos la bandera o no
> en un logo.
>
> Sin ir más lejos, el tema de la asociación OSM es sigue encallado, lo que
> nos podría dar opción a constituirnos como "local chapter"  y no vendría
> cualquiera a decirnos qué hemos de hacer o a no reconocernos como comunidad
> (algo, por otro lado que me parece intolerable por su parte).
>
> Un saludo
>
> Miguel
>
>
> --
> *Miguel Sevilla-Callejo*
> Doctor en Geografía
>
> 2018-01-03 14:10 GMT+01:00 Javier Sánchez Portero :
>
>> Un dato en serio: El logo se está visualizando ahora mismo a 82x80
>> píxeles y creo que debería tener siempre un tamaño algo menor que el de OSM
>> (160x160). Eso no da para muchas filigranas.
>>
>> Y otro en broma: No estoy de acuerdo con usar el toro, prefiero rescatar
>> la gitanilla ahora que han desaparecido los televisores de tubo.
>>
>> El 3 de enero de 2018, 11:49, dazer  escribió:
>>
>>> Tiene el significado que quiera cada uno darle.
>>> Los logos no se supone que unan. Se supone que representan o identifican.
>>>
>>> En este caso identifica a un país; no a una comunidad de personas ni a un
>>> "pueblo". OSM representa realidades y conceptos. No sentimientos
>>> nacionales.
>>> La bandera es un concepto y una realidad identificable.
>>>
>>> La página de España, creo, no es para los españoles y sus sensibilidades,
>>> sino para coordinar los trabajos en España. Y eso implica que se pueda
>>> unir
>>> gente que no es de España; me parecería adecuado recibirles en un sitio
>>> que
>>> sea familar.
>>> Me parecería un error masivo no usar la bandera, independientemente de
>>> que a
>>> mi me gustase otro encaje territorial e institucional. Error porque la
>>> bandera es fácilmente reconocible e identificable dentro y, sobretodo,
>>> fuera
>>> de las fronteras. Es el símbolo que une con el resto del mundo.
>>>
>>> La opción de usar la figura del territorio (más Canarias, Baleares,
>>> ciudades
>>> autónomas, y plazas de soberanía menores) siempre se me ha antojado
>>> cutre:
>>> porque el territorio reconocible es la península (junto a Portugal), no
>>> la
>>> figura del país. Y peca de que en formatos pequeños, los territorios de
>>> la
>>> costa Africana no se ven (y merecen tanta representación como cualquier
>>> otro).
>>>
>>> Y ya medio jocoso, medio en serio: ya que otros países adoptan figuras
>>> folklóricas, estaría bien poner un toro de Osborne.
>>>
>>>
>>>
>>> --
>>> 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
>>
>>
>
> ___
> 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

[Talk-it] Confine italo-francese sul Monte Bianco

[Dario Crespi]

Ciao,

casualmente ho visto che il confine tra Italia e Francia nei pressi del
Monte Bianco ha qualche problema:
http://www.openstreetmap.org/#map=14/45.8347/6.8516

Si può  sistemare?

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

Re: [Talk-cz] Prohlížeč talk-cz na osmap.cz

[Pavel Zbytovský]

ad majka) tohle byla spíš vlastnost než chyba, ale asi to upravím - to je
easy.

ad marián) dík! fixnu. Ještě by to ten JPEG vlastně mohlo i rovnou
zobrazit..

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

Re: [Talk-es] Cambio de logo para la comunidad OSM en España

[Iñaki]

Un sobresaliente por su comentario, don Miguel, un sobresaliente.

Iñaki


El 03/01/2018 a las 16:41, Miguel Sevilla-Callejo escribió:

Hola,

Por fin tengo un momento a para opinar sobre el asunto.

Hace tiempo, creo que ya hace un par de años, que al abrir el grupo de 
Telegram e ir a actualizar algún aspecto de la Wiki me decidí junto 
con Oscar Zorrilla a pasar a vectorial un logo que alguien había hecho 
previamente añadiendo un "es" al logo de OSM.


Entonces pensamos sobre la conveniencia de tener uno u otro logo, como 
se está planteando en este momento y nos decidimos a poner el "ES" en 
mayúsculas, que es, junto con el "ESP" y el "724" el código ISO de 
España y en aquel momento le pareció bien a todo el mundo.


Mi parecer sigue siendo el mismo que el que tuve en su día, el que he 
expresado en otras vías, este logotipo de la comunidad española es el 
más adecuado puesto que es el políticamente más neutro y puesto que el 
perfíl geográfico del territorio español creo que no quedará bien 
(pues habrá que incluir los los archipiélagos y las ciudades autónomas 
africanas).


Como ya se ha comentado en los anteriores mensajes tenemos que buscar 
soluciones que unan pues somos comunidad y desafortunadamente en 
España el tema de la bandera es uno de ellos.


Dicho todo lo anterior creo que tenemos temas mucho más relevantes y 
tareas abiertas más importantes que discutir que si ponemos la bandera 
o no en un logo.


Sin ir más lejos, el tema de la asociación OSM es sigue encallado, lo 
que nos podría dar opción a constituirnos como "local chapter"  y no 
vendría cualquiera a decirnos qué hemos de hacer o a no reconocernos 
como comunidad (algo, por otro lado que me parece intolerable por su 
parte).


Un saludo

Miguel


--
*Miguel Sevilla-Callejo*
Doctor en Geografía

2018-01-03 14:10 GMT+01:00 Javier Sánchez Portero 
>:


Un dato en serio: El logo se está visualizando ahora mismo a 82x80
píxeles y creo que debería tener siempre un tamaño algo menor que
el de OSM (160x160). Eso no da para muchas filigranas.

Y otro en broma: No estoy de acuerdo con usar el toro, prefiero
rescatar la gitanilla ahora que han desaparecido los televisores
de tubo.

El 3 de enero de 2018, 11:49, dazer > escribió:

Tiene el significado que quiera cada uno darle.
Los logos no se supone que unan. Se supone que representan o
identifican.

En este caso identifica a un país; no a una comunidad de
personas ni a un
"pueblo". OSM representa realidades y conceptos. No
sentimientos nacionales.
La bandera es un concepto y una realidad identificable.

La página de España, creo, no es para los españoles y sus
sensibilidades,
sino para coordinar los trabajos en España. Y eso implica que
se pueda unir
gente que no es de España; me parecería adecuado recibirles en
un sitio que
sea familar.
Me parecería un error masivo no usar la bandera,
independientemente de que a
mi me gustase otro encaje territorial e institucional. Error
porque la
bandera es fácilmente reconocible e identificable dentro y,
sobretodo, fuera
de las fronteras. Es el símbolo que une con el resto del mundo.

La opción de usar la figura del territorio (más Canarias,
Baleares, ciudades
autónomas, y plazas de soberanía menores) siempre se me ha
antojado cutre:
porque el territorio reconocible es la península (junto a
Portugal), no la
figura del país. Y peca de que en formatos pequeños, los
territorios de la
costa Africana no se ven (y merecen tanta representación como
cualquier
otro).

Y ya medio jocoso, medio en serio: ya que otros países adoptan
figuras
folklóricas, estaría bien poner un toro de Osborne.



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





___
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: [OSM-talk-fr] Question sur le rendu standard !

[althio]

>> Où fait-on remonter ce type de problème (si c'est bien un problème ?) ?
>
> ici https://github.com/gravitystorm/openstreetmap-carto/issues
> et là https://github.com/cquest/osmfr-cartocss/issues

En fait, cela doit déjà être connu :
https://github.com/gravitystorm/openstreetmap-carto/issues/2428
https://github.com/gravitystorm/openstreetmap-carto/issues/2511
https://github.com/gravitystorm/openstreetmap-carto/issues/1465

et voire "au-dessus", améliorations en cours dans les dernières
versions de mapnik
https://github.com/mapnik/mapnik/issues/3550
https://github.com/mapnik/mapnik/issues/3558
https://github.com/mapnik/mapnik/pull/3771
https://github.com/mapnik/mapnik/pull/3811

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

Re: [OSM-talk-fr] *** BULK *** Re: Contours des IRIS

[Philippe Verdy]

Je n'ai jamais parlé pas d'importation directe mais bien d'intégration
(comme tout ce qui se fait dans OSM de toute façon!) Ce n'est pas parce que
le GéoFLA était imprécis qu'on n'a pas intégré les limites communales à
l'aide d'une meilleure source (le cadastre malgré qu'il n'était même pas
vectorisé en grande partie) en faisant les conflations nécessaires et qu'on
a cherché à cependant respecter le même découpage que l'INSEE (et on n'a
pas atendu non plus que l'INSEE se mette à jour quand les communes ont
changé on avait fait le travail avant).

Ce n'est pas si gros que ça. Pour le suivi des mises à jour on pourra
encore utiliser les données INSEE des IRIS à titre de comparaison et pour
les rapprochements utiliser les identifiants INSEE en référence. L'INSEE
suivra alors, et on peut prendre de l'avance sur lui en nous basant sur des
efforts plus précoces et plus volontaristes des collectivités locales qui
veulent développer (et ont besoin) de maillage fin. L'INSEE fera ses études
à la demande des collectivité et suivra le cadre de travail qu'elles
définissent plus précisément. Elle fera ses statistiques sur cette base
même si en attendant elle ne publie pas les mises à jour précises de ses
IRIS. Mais l'INSEE ferait mieux de revoir sa politique de divulgation pour
éviter les simplifications géométriques (qui suffisent pour ses propres
cartes mais pas pour nous qui voudrions des cartes plus précises à la
portée de ce que voient réellement les citoyens concernés).

On en a déjà parlé concernant le zonage électoral : les arrêtés
préfectoraux ou ministériels sont insuffisants. La presse locale
s'intéresse à des zonages précis que l'INSEE ou le ministère de l'Intérieur
ne fournit toujours pas. C'est pourtant essentiel de savoir pour un citoyen
s'il est ou pas concerné réellement par une politique locale ou un
aménagement et où il peut agir (ou militer en cas de besoin de changement).

C'est pour ça que j'ai demandé quels tags on pourrait utiliser, pour
commencer dans quelques villes et ensuite développer les méthodes plus
systématiques pour achever ça: ce n'est pas insurmontable, cela concerne
des villes où on a déjà des données très précises et on a déjà les autres
découpages administratifs pour nous aligner dessus.

A titre d'expérience initiale on peut éviter de commencer par Paris (mais
dont les IRIS découpent les arrondissements et reprennent aussi les limites
des grands quartiers et sous-quartiers administratif: l'expérience peut
être tentée déjà dans un sous-quartier, étendu ensuite à tout le quartier,
puis l'arrondissement). ceci fait on pourra voir si le découpage électoral
colle lui aussi réellement (ce qui devrait être le cas normalement puisque
la loi impose l'équité des résidents  selon les règles de représentation
avec pas plus de 20% d'écart de représentation selon les décisions du
Conseil constitutionnel et que ce découpage doit s'appuyer sur la
population légale connue à une date donnée, celle utilisée par l'INSEE
justement à partir des IRIS utilisés pour ses enquêtes).

Pas mal de communes sont simples à faire avec seulement deux ou 3 IRIS, et
certains départements n'ont que 3 communes découpées.

Bref je repose la question à laquelle personne ne veut répondre. Quel tag :
boundary=statistic ?

Le 3 janvier 2018 à 15:58, Vincent de Château-Thierry  a
écrit :

> Bonjour,
> et heureuse année 2018 :)
>
> On peut considérer les IRIS comme de peu d'intérêt, mais ils restent un
> outil d'analyse auquel sont rattachés pas mal de stats [1], que ça plaise
> ou non. L'IGN continue (pour combien de temps ?) de commercialiser leur
> découpage recalé sur la BD Topo [2]. Bref, ils sont encore dans le paysage
> géomatique pour quelques temps...
> Partant de là, je trouve pertinent qu'on cherche à disposer de leurs
> limites dans OSM, ne serait-ce que pour avoir via la même base le moyen de
> géocoder des ressources ET de les sectoriser en IRIS. Difficile d'avoir une
> cohérence géométrique avec des contenus maintenus séparément. Et comme
> d'habitude, on n'a pas à préjuger de qui s'en servira.
> Le bémol, déjà souligné plus tôt dans ce fil, c'est la qualité géométrique
> des IRIS OSM-compatibles en terme de licence. Il s'agit du débat qu'on a eu
> au moment de la libération du GeoFLA il y a 5 ans : la donnée sémantique
> nous intéressait, mais la précision géométrique était incompatible avec
> OSM, donc on n'a pas formellement intégré le GeoFLA. C'est pareil
> aujourd'hui avec les IRIS : en l'état je ne suis pas pour utiliser la
> géométrie des IRIS de Contours-IRIS, ce serait une juxtaposition de données
> plus qu'une intégration.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-es] Cambio de logo para la comunidad OSM en España

[Miguel Sevilla-Callejo]

Hola,

Por fin tengo un momento a para opinar sobre el asunto.

Hace tiempo, creo que ya hace un par de años, que al abrir el grupo de
Telegram e ir a actualizar algún aspecto de la Wiki me decidí junto con
Oscar Zorrilla a pasar a vectorial un logo que alguien había hecho
previamente añadiendo un "es" al logo de OSM.

Entonces pensamos sobre la conveniencia de tener uno u otro logo, como se
está planteando en este momento y nos decidimos a poner el "ES" en
mayúsculas, que es, junto con el "ESP" y el "724" el código ISO de España y
en aquel momento le pareció bien a todo el mundo.

Mi parecer sigue siendo el mismo que el que tuve en su día, el que he
expresado en otras vías, este logotipo de la comunidad española es el más
adecuado puesto que es el políticamente más neutro y puesto que el perfíl
geográfico del territorio español creo que no quedará bien (pues habrá que
incluir los los archipiélagos y las ciudades autónomas africanas).

Como ya se ha comentado en los anteriores mensajes tenemos que buscar
soluciones que unan pues somos comunidad y desafortunadamente en España el
tema de la bandera es uno de ellos.

Dicho todo lo anterior creo que tenemos temas mucho más relevantes y tareas
abiertas más importantes que discutir que si ponemos la bandera o no en un
logo.

Sin ir más lejos, el tema de la asociación OSM es sigue encallado, lo que
nos podría dar opción a constituirnos como "local chapter"  y no vendría
cualquiera a decirnos qué hemos de hacer o a no reconocernos como comunidad
(algo, por otro lado que me parece intolerable por su parte).

Un saludo

Miguel


--
*Miguel Sevilla-Callejo*
Doctor en Geografía

2018-01-03 14:10 GMT+01:00 Javier Sánchez Portero :

> Un dato en serio: El logo se está visualizando ahora mismo a 82x80 píxeles
> y creo que debería tener siempre un tamaño algo menor que el de OSM
> (160x160). Eso no da para muchas filigranas.
>
> Y otro en broma: No estoy de acuerdo con usar el toro, prefiero rescatar
> la gitanilla ahora que han desaparecido los televisores de tubo.
>
> El 3 de enero de 2018, 11:49, dazer  escribió:
>
>> Tiene el significado que quiera cada uno darle.
>> Los logos no se supone que unan. Se supone que representan o identifican.
>>
>> En este caso identifica a un país; no a una comunidad de personas ni a un
>> "pueblo". OSM representa realidades y conceptos. No sentimientos
>> nacionales.
>> La bandera es un concepto y una realidad identificable.
>>
>> La página de España, creo, no es para los españoles y sus sensibilidades,
>> sino para coordinar los trabajos en España. Y eso implica que se pueda
>> unir
>> gente que no es de España; me parecería adecuado recibirles en un sitio
>> que
>> sea familar.
>> Me parecería un error masivo no usar la bandera, independientemente de
>> que a
>> mi me gustase otro encaje territorial e institucional. Error porque la
>> bandera es fácilmente reconocible e identificable dentro y, sobretodo,
>> fuera
>> de las fronteras. Es el símbolo que une con el resto del mundo.
>>
>> La opción de usar la figura del territorio (más Canarias, Baleares,
>> ciudades
>> autónomas, y plazas de soberanía menores) siempre se me ha antojado cutre:
>> porque el territorio reconocible es la península (junto a Portugal), no la
>> figura del país. Y peca de que en formatos pequeños, los territorios de la
>> costa Africana no se ven (y merecen tanta representación como cualquier
>> otro).
>>
>> Y ya medio jocoso, medio en serio: ya que otros países adoptan figuras
>> folklóricas, estaría bien poner un toro de Osborne.
>>
>>
>>
>> --
>> 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
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-cz] Statistika využití CZ:IPRPraha:ortofoto

[Jethro]

Zdar,
určitě pruhy, prezentovat jako "Zlepšení pro mnohé automobilové
navigace" ;-) Já jsem jich taky zmapoval docela dost právě podle (a
díky tomu, že se uvolnily) IPR ortofoto.
MSF
Jethro

2018-01-03 15:47 GMT+01:00 Jan Martinec :
> Ahoj,
>
> to je super, že to aspoň pár lidí využilo.
> Díky za uznání, ale nějak mě nenapadá jedna velká konkrétní věc, kterou jsem
> s tím dělal - většinou to bylo menší využití v rámci úprav něčeho většího -
> budovy, průchody, vodní toky.
>
> Možná pražské mosty - přidával jsem pomocí ortofota pilíře, a zcela určitě
> jsem udělal i spoustu dopravních pruhů (počet, směr, omezení, řazení v
> nich).
>
> Každopádně díky, žes to zařídil - takhle kvalitní podklady kdybychom tak
> měli všude...
>
> Zdar,
> Honza Piškvor Martinec
>
>
> Dne 3.1.2018 v 14:30 Matej Lieskovský napsal(a):
>>
>> Ahoj!
>>
>> Jak si možná vzpomínáte, před necelým rokem jsem pomohl získat povolení
>> k využití ortofotek IPR. Díky tomu nyní máme přístup k snímkům celé
>> Prahy a okolí, které jsou 2x ročně aktualizovány. V rámci dohody jsem
>> slíbil počítání statistik. Zatím čekám na zveřejnění nového planet.osm,
>> ale tady jsou statistiky k 25.12.:
>>
>> Data IPR využilo 8 uživatelů ve 396 change setech, které se týkaly 46890
>> objektů.
>>
>> Až budu mít zpracovaná novější data, tak bych jim tohle poslal jako
>> součást většího reportu.
>>
>> Pokud proti tomu nikdo nic nemá, tak bych tam také použil frázi cca typu
>> "Dovolte, abych Vám jménem české komunity přispěvatelů do OSM poděkoval."
>>
>> Taky bych tam rád napsal nějaká "pěkná" využití těch fotek. Překreslení
>> tramvajových tratí bylo z velké části pomocí IPR fotek, já jsem dělal
>> pár zlepšení porkytí parků (Valdštejná zahrada, Vojanovy sady, Malešický
>> park, Centrální park, Vyšehrad...), ale vykoukat další věci z těch
>> changesetů je trochu nad moje možnosti. Víte někdo o něčem, co by se
>> dalo takhle vypíchnout? Vím, že Piškvor toho taky udělal hodně, ale
>> zatím nevím, jak to pěkně popsat.
>>
>> Ať se daří!
>>
>> Matej
>>
>> PS: Jo, snažím se dát IPR něco, co zní dobře. Oni to použijí jako
>> "podívejte se, jak je IPR užitečný" a výměnou za to nám snad do budoucna
>> dají více dat.
>>
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

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

Re: [OSM-talk-fr] Question sur le rendu standard !

[althio]

> Bonjour et bonne année à toutes et tous !

Itou à toutes et itou à tous :)

> dans le rendu carto standard (et fr), le name s'affiche parfois de façon 
> "décalé".

Tout cela est bien bizarre en effet, sacré pioche.

> Où fait-on remonter ce type de problème (si c'est bien un problème ?) ?

ici https://github.com/gravitystorm/openstreetmap-carto/issues
et là https://github.com/cquest/osmfr-cartocss/issues

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

Re: [OSM-talk-fr] *** BULK *** Re: Contours des IRIS

[Vincent de Château-Thierry]

Bonjour,
et heureuse année 2018 :)

> De: "Philippe Verdy" 
> 
> Je ne vois pas en quoi c'est "inutile".
> 
> Le 3 janvier 2018 à 13:44, Christian Quest < cqu...@openstreetmap.fr
> > a écrit :
> 
> Les IRIS sont un pis aller en terme de maillage statistique. Faute de
> mieux ils sont malheureusement encore trop utilisés. Ils sont de
> taille communale la plupart du temps et pas à jour ailleurs.
> 
> Ils ne sont réellement utiles que pour projeter des statistiques
> réalisées par l'INSEE avec ce maillage, pour le reste, je ne vois
> pas trop.
> 
> Dans les quartiers où la population a changé, c'est sûr que ça ne
> représente plus grand chose de significatif, y compris les stats si
> elles n'ont pas été remises à jour par une enquête de terrain
> complète.

On peut considérer les IRIS comme de peu d'intérêt, mais ils restent un outil 
d'analyse auquel sont rattachés pas mal de stats [1], que ça plaise ou non. 
L'IGN continue (pour combien de temps ?) de commercialiser leur découpage 
recalé sur la BD Topo [2]. Bref, ils sont encore dans le paysage géomatique 
pour quelques temps...
Partant de là, je trouve pertinent qu'on cherche à disposer de leurs limites 
dans OSM, ne serait-ce que pour avoir via la même base le moyen de géocoder des 
ressources ET de les sectoriser en IRIS. Difficile d'avoir une cohérence 
géométrique avec des contenus maintenus séparément. Et comme d'habitude, on n'a 
pas à préjuger de qui s'en servira.
Le bémol, déjà souligné plus tôt dans ce fil, c'est la qualité géométrique des 
IRIS OSM-compatibles en terme de licence. Il s'agit du débat qu'on a eu au 
moment de la libération du GeoFLA il y a 5 ans : la donnée sémantique nous 
intéressait, mais la précision géométrique était incompatible avec OSM, donc on 
n'a pas formellement intégré le GeoFLA. C'est pareil aujourd'hui avec les IRIS 
: en l'état je ne suis pas pour utiliser la géométrie des IRIS de 
Contours-IRIS, ce serait une juxtaposition de données plus qu'une intégration. 

vincent

[1] : https://www.insee.fr/fr/statistiques?debut=0=ICQ-1
[2] : http://professionnels.ign.fr/irisge

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

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[Vincent Frison]

@althio: Merci pour le lien ! J'ai rajouté mon petit commentaire mais sans
trop d'espoir puisque le ticket a déjà été clôturé :(

@Jo: Oui le rendu sur hikebikemap.org est pas mal mais perso je préfère
opentopomap.org pour un zoom < 9 et opensnowmap.org pour un zoom > 9.


Le 3 janvier 2018 à 14:59, althio  a écrit :

> Non tu n'es pas le seul, il suffit d'aller voir la question sur :
> https://github.com/gravitystorm/openstreetmap-carto/issues/2931
>
> -- althio
>
>
> 2017-12-28 15:10 GMT+01:00 Vincent Frison :
> > Hello,
> >
> > Je sais pas si je suis le seul mais pour moi les cartes affichant le
> relief,
> > c'est à dire avec hillshade et/ou courbes de niveaux, sont bien plus
> jolies
> > que celles sont relief. Je dirais même qu'en plus d'être plus jolies
> elles
> > sont beaucoup plus claires car elles permettent de se repérer plus
> > facilement avec le relief.
> >
> > Le souci c'est que le rendu par défaut de osm.org n'a pas le relief et
> je
> > trouve ça plus que dommage.
> >
> > Il y a des sites proposant des rendus avec reliefs qui sont magnifiques
> > comme par ex. http://opentopomap.org ou http://opensnowmap.org. Le
> problème
> > c'est qu'ils n'ont pas la rapidité d'osm.org, ni toutes ses
> fonctionnalités
> > (principalement celle qui permet de chercher les objets afin de voir tous
> > les détails).
> >
> > Certes il y a le layer "carte cyclable" d'osm.org mais malheureusement
> le
> > relief est assez mal rendu et puis surtout il est vraiment orienté pour
> les
> > vélos en masquant la plupart des informations pour mettre en valeur
> celles
> > utiles aux cyclistes.
> >
> > J'ai l'impression que ça ne serait pas un énorme travail de rajouter le
> > relief sur le rendu par défaut d'osm.org. L'idée serait d'avoir une
> option
> > pour afficher le hillshade et les courbes de niveaux. c'est à dire 2
> petites
> > checkboxes en plus de celles existantes (permettant d'afficher les notes
> de
> > carte, etc.).
> >
> > Sur le site http://opensnowmap.org en allant dans les settings on peut
> > afficher le rendu standard d'OSM au lieu de celui d'OpenSnow.  J'ai
> > l'impression que c'est juste un layer supplémentaire (avec hillshade et
> > courbes de niveaux) qui s'affiche en plus de celui du rendu standard..
> mais
> > qui du coup n'a plus rien à voir avec le rendu classique, pour moi la
> valeur
> > ajoutée est vraiment énorme !
> >
> > Suis je le seul à qui ça manque ?
> >
> > Et à qui devrais  je demander cette évolution ? Sur un mailing list
> > particulière ou directement en créant une issue ici:
> > https://github.com/gravitystorm/openstreetmap-carto ?
> >
> > Merci, Vincent.
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-cz] Statistika využití CZ:IPRPraha:ortofoto

[Jan Martinec]

Ahoj,

to je super, že to aspoň pár lidí využilo.
Díky za uznání, ale nějak mě nenapadá jedna velká konkrétní věc, kterou 
jsem s tím dělal - většinou to bylo menší využití v rámci úprav něčeho 
většího - budovy, průchody, vodní toky.


Možná pražské mosty - přidával jsem pomocí ortofota pilíře, a zcela 
určitě jsem udělal i spoustu dopravních pruhů (počet, směr, omezení, 
řazení v nich).


Každopádně díky, žes to zařídil - takhle kvalitní podklady kdybychom tak 
měli všude...


Zdar,
Honza Piškvor Martinec


Dne 3.1.2018 v 14:30 Matej Lieskovský napsal(a):

Ahoj!

Jak si možná vzpomínáte, před necelým rokem jsem pomohl získat povolení
k využití ortofotek IPR. Díky tomu nyní máme přístup k snímkům celé
Prahy a okolí, které jsou 2x ročně aktualizovány. V rámci dohody jsem
slíbil počítání statistik. Zatím čekám na zveřejnění nového planet.osm,
ale tady jsou statistiky k 25.12.:

Data IPR využilo 8 uživatelů ve 396 change setech, které se týkaly 46890
objektů.

Až budu mít zpracovaná novější data, tak bych jim tohle poslal jako
součást většího reportu.

Pokud proti tomu nikdo nic nemá, tak bych tam také použil frázi cca typu
"Dovolte, abych Vám jménem české komunity přispěvatelů do OSM poděkoval."

Taky bych tam rád napsal nějaká "pěkná" využití těch fotek. Překreslení
tramvajových tratí bylo z velké části pomocí IPR fotek, já jsem dělal
pár zlepšení porkytí parků (Valdštejná zahrada, Vojanovy sady, Malešický
park, Centrální park, Vyšehrad...), ale vykoukat další věci z těch
changesetů je trochu nad moje možnosti. Víte někdo o něčem, co by se
dalo takhle vypíchnout? Vím, že Piškvor toho taky udělal hodně, ale
zatím nevím, jak to pěkně popsat.

Ať se daří!

Matej

PS: Jo, snažím se dát IPR něco, co zní dobře. Oni to použijí jako
"podívejte se, jak je IPR užitečný" a výměnou za to nám snad do budoucna
dají více dat.


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




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

Re: [OSM-talk-fr] *** BULK *** Re: Contours des IRIS

[Philippe Verdy]

Certes les données géographiques de l'INSEE sont améliorables (merci à la
Métropole de Rennes de vouloir les définir plus précisément elle-même:
l'INSEE suivra car à ce niveau elle est obligée de s'accorder avec les
collectivités locales). L'INSEE publiera donc des mises à jour pour chaque
ville qui s'y mettra (et rien n'empêche une ville de développer un maillage
encore plus fin, si elle en a la capacité et les moyens).
Je ne crois pas du tout que c'est un "pis aller", c'est une base
essentielle de travail, le minimum exigé par la loi actuelle (qui évoluera
pour tenir compte des besoins et si les citoyens l'exigent pour comprendre
les décions prises sur leur territoire).

On a tout à gagner à rendre ce maillage visible, public, auditable par les
citoyens de base et pas seulement soumis aux manipulations de quelques
élites qui peuvent décider de les trafiquer pour des raisons électoralites
voire clientélistes: tout changement à ce maillage doit être détectable,
contrôlable par tous (pour éviter des manipulations locales consistant à
ajouter tel ou tel immeuble ou en retirer un autre pour masquer
statistiquement une opération prévue et faire croire que cela n'aura pas
d'impact négatif.

A l'heure où des tas de services publics sont remaniés administrativement
et ferment du jour au lendemain sans aucune concertation ni consultation
publique mais juste des explications données après coup sur des
statistiques manipulées, il serait bon de savoir qu'il y a une réelle
égalité de traitement des citoyens et le respect de l'équité (relative) des
droits pour que ne s'arrête la création de territoires exclus des
politiques publiques (mais qui doivent pourtant payer pour les autres
territoires voisins qui sont les seuls à bénéficier des efforts publics et
sinon subir des temps de transport ou payer plus cher l'accès aux services
de proximité parce qu'ils ne font plus partie du territoire visé par un
aménagement public ou n'en subiront que les nuisances).

La statistique c'est l'instrument de base de l'exercice du pouvoir de
l'autorité publique. Elle justifie tout, mais doit la statistique elle-même
se justifier et correspondre à la définition et l'usage des territoires par
ceux qui y vivent réellement.

Les IRIS ne sont pas les seuls indicateurs, on a aussi les PLU, les PDU où
figurent des tas de décisions contestables... mais pas contestées car
masquées ou rendues incompréhensibles et non auditables par le commun des
mortels à qui on ne fournit que des données très vagues. L'INSEE a du
travail à faire pour rendre ses découpages fins réellement conformes à la
réalité : ce découpage devrait être aussi exact que ce qui existe dans les
SIG des communes et administrations : on nous DOIT cette information selon
la loi française elle-même (et aussi les directives européennes INSPIRE qui
tardent encore à s'imposer à nos gouvernants).

Le 3 janvier 2018 à 11:51, REBOUX Maël  a
écrit :

> Bonjour,
>
>
>
> Les IRIS sont un pis aller en terme de maillage statistique. Faute de
> mieux ils sont malheureusement encore trop utilisés. Ils sont de taille
> communale la plupart du temps et pas à jour ailleurs.
>
> Nous sommes un certain nombre de « grosses » collectivités territoriales à
> avoir réclamer à l’INSEE il y a déjà qqs années maintenant une mise à jour
> de ces limites, notamment dans les zones « dynamiques » (à l’urbanisation
> qui bouge vite et donc où la population croît). L’INSEE n’a pas accédé à
> nos demandes ce qui fait que ces maillages sont obsolètes sur les zones qui
> en auraient besoin.
>
>
>
> Nous en sommes rendus à publier des mises à jour locales plus à jour des
> réalités du terrain. Exemple : https://public.sig.
> rennesmetropole.fr/geonetwork/srv/fre/catalog.search#/
> metadata/df789a3f-9980-4629-95be-50a8b04eac3c
>
>
>
> *Dans un souci de mise en adéquation des contours des différents zonages
> de gestion (quartier, périmètres électoraux...), Rennes Métropole a procédé
> à une numérisation des Iris en se basant sur des référentiels internes. Du
> fait de l'évolution des communes depuis la mise en œuvre des Iris, certains
> contours ont été revus en conséquence. De ce fait, cette couche n'est pas
> la couche officielle fournie par l'Insee (cf la description de la
> généalogie).*
>
>
>
> Cdt,
>
>
>
> *Maël REBOUX*
> Service Information Géographique Rennes Métropole
> Chargé de mission "diffusion"
>
> 02 99 86 63 71
>
> Twitter : @mael_reboux_ig 
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[Jo]

http://hikebikemap.org/ montre le reliëf d'une très belle façon et il y a
moyen de visualiser beaucoup d'itinéraires. Je pense que cyclemap le fait
aussi.

Polyglot


2018-01-03 14:59 GMT+01:00 althio :

> Non tu n'es pas le seul, il suffit d'aller voir la question sur :
> https://github.com/gravitystorm/openstreetmap-carto/issues/2931
>
> -- althio
>
>
> 2017-12-28 15:10 GMT+01:00 Vincent Frison :
> > Hello,
> >
> > Je sais pas si je suis le seul mais pour moi les cartes affichant le
> relief,
> > c'est à dire avec hillshade et/ou courbes de niveaux, sont bien plus
> jolies
> > que celles sont relief. Je dirais même qu'en plus d'être plus jolies
> elles
> > sont beaucoup plus claires car elles permettent de se repérer plus
> > facilement avec le relief.
> >
> > Le souci c'est que le rendu par défaut de osm.org n'a pas le relief et
> je
> > trouve ça plus que dommage.
> >
> > Il y a des sites proposant des rendus avec reliefs qui sont magnifiques
> > comme par ex. http://opentopomap.org ou http://opensnowmap.org. Le
> problème
> > c'est qu'ils n'ont pas la rapidité d'osm.org, ni toutes ses
> fonctionnalités
> > (principalement celle qui permet de chercher les objets afin de voir tous
> > les détails).
> >
> > Certes il y a le layer "carte cyclable" d'osm.org mais malheureusement
> le
> > relief est assez mal rendu et puis surtout il est vraiment orienté pour
> les
> > vélos en masquant la plupart des informations pour mettre en valeur
> celles
> > utiles aux cyclistes.
> >
> > J'ai l'impression que ça ne serait pas un énorme travail de rajouter le
> > relief sur le rendu par défaut d'osm.org. L'idée serait d'avoir une
> option
> > pour afficher le hillshade et les courbes de niveaux. c'est à dire 2
> petites
> > checkboxes en plus de celles existantes (permettant d'afficher les notes
> de
> > carte, etc.).
> >
> > Sur le site http://opensnowmap.org en allant dans les settings on peut
> > afficher le rendu standard d'OSM au lieu de celui d'OpenSnow.  J'ai
> > l'impression que c'est juste un layer supplémentaire (avec hillshade et
> > courbes de niveaux) qui s'affiche en plus de celui du rendu standard..
> mais
> > qui du coup n'a plus rien à voir avec le rendu classique, pour moi la
> valeur
> > ajoutée est vraiment énorme !
> >
> > Suis je le seul à qui ça manque ?
> >
> > Et à qui devrais  je demander cette évolution ? Sur un mailing list
> > particulière ou directement en créant une issue ici:
> > https://github.com/gravitystorm/openstreetmap-carto ?
> >
> > Merci, Vincent.
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] disused:

[demon.box]

Alfredo Gattai wrote
> Ciao,
> 
> forse e' OT ma l'argomento mi interessa.
> Fermo restando che non si mappa per il rendering trovo opinabile che una
> cosa non utilizzata sparisca. Se viene totalmente rimossa dovrebbe sparire
> ma non se e' semplicemente inutilizzata. Faccio un parallelo con il mondo
> della nautica che e' il mio campo, se un cavo sottomarino e' inutilizzato
> prende un attributo "disused" questo perche' per un natante (specie se
> peschereccio) la presenza di un cavo sottomarino e' un rischio che va
> segnalato.
> Un rifugio, anche se inutlizzato, dovrebbe essere sempre visibile perche'
> potrebbe rappresentare un parziale rifugio d'emergenza. Ovviamente sono
> tutti casi limite credo che nessuno dovrebbe affidarsi completamente a
> quel
> che vedo sullo schermo.
> Altro problema che vedo legato al prefix e' che di fatto se fai una query
> cercando ad esempio le railway rischi di non trovare quelle che sono
> disused:railway, mi e' capitato con un percorso escursionistico dove
> invece
> di mettere access=no o prohibited perche' era chiuso, qualcuno ha
> preferito
> mettere disused:highway=path. Un sentiero chiuso non e' sparito, e' solo
> chiuso. Se una frana se lo e' portato via lo si cancella.
> 
> Non so se mi sono spiegato bene ma nella cartografia elettronica in
> generale si codifica un oggetto per quello che e' poi se ne definisce lo
> stato con opportuni attributi, non si cambia l'oggetto.
> 
> Alfredo

Ciao Alfredo, bravo hai esplicato esattamente quello che è il mio dubbio di
fondo: perchè preferire disused: a disused=yes?

Anche per gli appostamenti di caccia vale, secondo me, lo stesso identico
discorso: se passo di lì e mi sembra (dalla mia osservazione oculare) che
non sia attivo non vedo però perchè farlo "sparire" utilizzando
disused:amenity=hunting_stand quando comunque potrebbe costituire un
"pericolo" dal momento che non ho la certezza assoluta con sia mai più
utilizzato...
In altre parole anch'io non vedo perchè "stravolgere" la key del tag con
disused: quando è così comodo e semplice aggiungere disused=yes, in questo
modo oltre al rendering che non si perde, anche una qualsiasi query
individuerà sempre l'oggetto con la specifica del disused=yes
Grazie
--enrico




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

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

Re: [OSM-talk-fr] *** BULK *** Re: Contours des IRIS

[Philippe Verdy]

C'est pourtant la base des stats officielles et la source du découpage
administratif ou électoral. C'est essentiel aussi pour comprendre comment
ça marche et ensuite avoir une vue citoyenne des décisions prises par les
collectivités ou l'Etat. Ca donne aussi une vue sur l'équité de traitement
des territoires (populations réellement desservies par les services
publics, les transports, les offres commerciales, les plans d'aménagements,
les concertations publiques avec les citoyens sur les choix
d'implantation). Et c'est utile au commerce aussi.
Je ne vois pas en quoi c'est "inutile".

Le 3 janvier 2018 à 13:44, Christian Quest  a
écrit :

> Le 3 janvier 2018 à 11:51, REBOUX Maël  a
> écrit :
>
>> Bonjour,
>>
>>
>>
>> Les IRIS sont un pis aller en terme de maillage statistique. Faute de
>> mieux ils sont malheureusement encore trop utilisés. Ils sont de taille
>> communale la plupart du temps et pas à jour ailleurs.
>>
>
>
> Ils ne sont réellement utiles que pour projeter des statistiques réalisées
> par l'INSEE avec ce maillage, pour le reste, je ne vois pas trop.
>
> Dans les quartiers où la population a changé, c'est sûr que ça ne
> représente plus grand chose de significatif, y compris les stats si elles
> n'ont pas été remises à jour par une enquête de terrain complète.
>
>
> --
> 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: [OSM-talk-fr] *** BULK *** Re: Contours des IRIS

[Philippe Verdy]

La plupart du temps ? Non, car il y a 16100 IRIS (une paille !) définis sur
1916 communes (les plus peuplées et les plus denses)
Rien que pour Paris il y en a 992 et c'est bien plus fin que les
arrondissements, les grands quartiers ou les sous-quartiers.
Les communes non concernées sont majoritaires mais elles sont beaucoup
moins peuplées et leur découpage administratif éventuel suffit pour un
ciblage plus fin.

  Valeurs
Dep Nombre de communes Nombre d'IRIS
01 17 72
02 9 79
03 10 62
04 4 24
05 3 33
06 27 364
07 9 35
08 9 52
09 4 18
10 8 57
11 10 69
12 6 40
13 67 773
14 17 145
15 3 17
16 8 48
17 15 94
18 5 51
19 5 41
21 16 132
22 15 79
23 3 9
24 9 45
25 15 117
26 14 92
27 10 77
28 8 61
29 30 202
2A 2 28
2B 5 23
30 25 149
31 32 294
32 4 19
33 40 339
34 42 278
35 28 210
36 4 34
37 12 119
38 42 258
39 5 42
40 11 49
41 5 43
42 24 194
43 5 16
44 44 339
45 17 136
46 2 13
47 9 49
48 3 9
49 20 165
50 7 77
51 12 147
52 3 32
53 8 43
54 25 166
55 2 14
56 24 137
57 34 234
58 8 40
59 112 810
60 19 125
61 5 38
62 70 345
63 17 124
64 17 127
65 5 44
66 21 108
67 26 241
68 22 151
69 53 529
70 5 21
71 20 121
72 13 112
73 10 59
74 29 140
75 20 992
76 42 370
77 51 299
78 65 487
79 8 65
80 6 78
81 10 81
82 4 38
83 37 299
84 21 139
85 18 84
86 11 90
87 13 90
88 9 49
89 9 53
90 3 25
91 46 353
92 35 615
93 39 613
94 42 522
95 51 429
971 25 129
972 17 124
973 7 54
974 23 343
Total général 1916 16100

Le 3 janvier 2018 à 11:51, REBOUX Maël  a
écrit :

> Bonjour,
>
>
>
> Les IRIS sont un pis aller en terme de maillage statistique. Faute de
> mieux ils sont malheureusement encore trop utilisés. Ils sont de taille
> communale la plupart du temps et pas à jour ailleurs.
>
> Nous sommes un certain nombre de « grosses » collectivités territoriales à
> avoir réclamer à l’INSEE il y a déjà qqs années maintenant une mise à jour
> de ces limites, notamment dans les zones « dynamiques » (à l’urbanisation
> qui bouge vite et donc où la population croît). L’INSEE n’a pas accédé à
> nos demandes ce qui fait que ces maillages sont obsolètes sur les zones qui
> en auraient besoin.
>
>
>
> Nous en sommes rendus à publier des mises à jour locales plus à jour des
> réalités du terrain. Exemple : https://public.sig.
> rennesmetropole.fr/geonetwork/srv/fre/catalog.search#/
> metadata/df789a3f-9980-4629-95be-50a8b04eac3c
>
>
>
> *Dans un souci de mise en adéquation des contours des différents zonages
> de gestion (quartier, périmètres électoraux...), Rennes Métropole a procédé
> à une numérisation des Iris en se basant sur des référentiels internes. Du
> fait de l'évolution des communes depuis la mise en œuvre des Iris, certains
> contours ont été revus en conséquence. De ce fait, cette couche n'est pas
> la couche officielle fournie par l'Insee (cf la description de la
> généalogie).*
>
>
>
> Cdt,
>
>
>
> *Maël REBOUX*
> Service Information Géographique Rennes Métropole
> Chargé de mission "diffusion"
>
> 02 99 86 63 71
>
> Twitter : @mael_reboux_ig 
>
>
>
> https://public.sig.rennesmetropole.fr   |  https://data.rennesmetropole.fr
>
>
>
>
>
> *De :* François Lacombe [mailto:fl.infosrese...@gmail.com]
> *Envoyé :* samedi 30 décembre 2017 17:27
> *À :* Discussions sur OSM en français
> *Objet :* *** BULK *** Re: [OSM-talk-fr] Contours des IRIS
>
>
>
> Bonjour
>
> S'agissant en plus de contours basés sur des quantités de population,
> leurs limitent varient à certains endroits j'immagine ?
>
> Les contours purement virtuels, qui n'ont pas plus d’interaction avec le
> reste des objets de la carte comme le bâti, les rivières, les
> infrastructures ont peut d'intérêt à se trouver véritablement dans OSM.
>
> On ne va pas non plus favoriser leur correction par les contributeurs en
> les plaçant sur la carte.
>
> Et je ne dis pas que ces données là n'ont pas d'intérêt, simplement qu'OSM
> ne va pas remplacer data.gouv
>
> François
>
>
>
> Le 30 décembre 2017 à 16:26, Christian Quest  a
> écrit :
>
>
>
> De plus les contours IRIS en LO sont approximatifs, ceux précis, sont
> payants...
>
>
>
> Le 29 décembre 2017 à 14:56, Cyrille37 OSM 
> a écrit :
>
> Salut
>
> Ça semble chouette d'avoir plus de données dans OSM, mais j'ai peur qu'il
> y a déjà énormément de mise à jour à suivre pour les éléments existants.
> Donc je pense que les IRIS sont très bien hors OSM et qu'il est facile pour
> qui sait faire des analyses, de les associés aux données OSM avec les
> outils adéquates.
>
> C/.
>
> Le 29/12/2017 à 13:56, Philippe Verdy a écrit :
>
> De nombreuses cartes statistiques pourraient utiliser les délimitations
> infracommunales (les IRIS).
>
> Elles sont libres (licence LO/OL).
>
> Peut-on envisager de les importer (sachant qu'on a déjà une partie de ces
> contours pour les frontières communales, et les quartiers administratifs,
> et que ces IRIS sont aussi à la base de la délimitation du fractionnement
> cantonal qui s'appuie sur les 

Re: [Talk-it] disused:

[Alfredo Gattai]

Ciao,

forse e' OT ma l'argomento mi interessa.
Fermo restando che non si mappa per il rendering trovo opinabile che una
cosa non utilizzata sparisca. Se viene totalmente rimossa dovrebbe sparire
ma non se e' semplicemente inutilizzata. Faccio un parallelo con il mondo
della nautica che e' il mio campo, se un cavo sottomarino e' inutilizzato
prende un attributo "disused" questo perche' per un natante (specie se
peschereccio) la presenza di un cavo sottomarino e' un rischio che va
segnalato.
Un rifugio, anche se inutlizzato, dovrebbe essere sempre visibile perche'
potrebbe rappresentare un parziale rifugio d'emergenza. Ovviamente sono
tutti casi limite credo che nessuno dovrebbe affidarsi completamente a quel
che vedo sullo schermo.
Altro problema che vedo legato al prefix e' che di fatto se fai una query
cercando ad esempio le railway rischi di non trovare quelle che sono
disused:railway, mi e' capitato con un percorso escursionistico dove invece
di mettere access=no o prohibited perche' era chiuso, qualcuno ha preferito
mettere disused:highway=path. Un sentiero chiuso non e' sparito, e' solo
chiuso. Se una frana se lo e' portato via lo si cancella.

Non so se mi sono spiegato bene ma nella cartografia elettronica in
generale si codifica un oggetto per quello che e' poi se ne definisce lo
stato con opportuni attributi, non si cambia l'oggetto.

Alfredo


2018-01-03 14:15 GMT+01:00 Cascafico Giovanni :

> Il building resta building=yes. É l'eventuale sua funzione che va in
> disuso: amenity, landuse, leisure ecc.
> Per il rendering, se un riparo mimetico non é più utilizzabile, trovo
> corretto che il suo rendering scompaia, cosa che non succederebbe con
> disused=yes
>
> Il 03/gen/2018 12:52, "demon.box"  ha scritto:
>
>> ciao, vorrei sistemare (il mio) utilizzo non corretto del tag disused=yes
>> visto che il wiki
>>
>> http://wiki.openstreetmap.org/wiki/IT:Key:disused:
>>
>> parla chiaro dicendo che è disincentivato a favore del prefisso disused:
>>
>> sono sincero che non ho ancora capito perchè sia disincentivato
>>
>> a parte il fatto che ad esempio nel caso di amenity=hunting_stand
>> guardando
>> taginfo
>>
>> trovo soltanto 11 volte disused:amenity=hunting_stand ... e mi sembra un
>> po'
>> pochino...
>>
>> ma a parte questo mi trovo in difficoltà quando ad esempio ho un edificio
>> che palesemente non è più utilizzato ma non è nemmeno un rudere come
>> faccio?
>> non posso fare disused:building=yes perchè la caratteristica del building
>> c'è ancora...
>> stesso discorso per un building=industrial ...
>> che dite?
>> grazie
>> --enrico
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[althio]

Non tu n'es pas le seul, il suffit d'aller voir la question sur :
https://github.com/gravitystorm/openstreetmap-carto/issues/2931

-- althio


2017-12-28 15:10 GMT+01:00 Vincent Frison :
> Hello,
>
> Je sais pas si je suis le seul mais pour moi les cartes affichant le relief,
> c'est à dire avec hillshade et/ou courbes de niveaux, sont bien plus jolies
> que celles sont relief. Je dirais même qu'en plus d'être plus jolies elles
> sont beaucoup plus claires car elles permettent de se repérer plus
> facilement avec le relief.
>
> Le souci c'est que le rendu par défaut de osm.org n'a pas le relief et je
> trouve ça plus que dommage.
>
> Il y a des sites proposant des rendus avec reliefs qui sont magnifiques
> comme par ex. http://opentopomap.org ou http://opensnowmap.org. Le problème
> c'est qu'ils n'ont pas la rapidité d'osm.org, ni toutes ses fonctionnalités
> (principalement celle qui permet de chercher les objets afin de voir tous
> les détails).
>
> Certes il y a le layer "carte cyclable" d'osm.org mais malheureusement le
> relief est assez mal rendu et puis surtout il est vraiment orienté pour les
> vélos en masquant la plupart des informations pour mettre en valeur celles
> utiles aux cyclistes.
>
> J'ai l'impression que ça ne serait pas un énorme travail de rajouter le
> relief sur le rendu par défaut d'osm.org. L'idée serait d'avoir une option
> pour afficher le hillshade et les courbes de niveaux. c'est à dire 2 petites
> checkboxes en plus de celles existantes (permettant d'afficher les notes de
> carte, etc.).
>
> Sur le site http://opensnowmap.org en allant dans les settings on peut
> afficher le rendu standard d'OSM au lieu de celui d'OpenSnow.  J'ai
> l'impression que c'est juste un layer supplémentaire (avec hillshade et
> courbes de niveaux) qui s'affiche en plus de celui du rendu standard.. mais
> qui du coup n'a plus rien à voir avec le rendu classique, pour moi la valeur
> ajoutée est vraiment énorme !
>
> Suis je le seul à qui ça manque ?
>
> Et à qui devrais  je demander cette évolution ? Sur un mailing list
> particulière ou directement en créant une issue ici:
> https://github.com/gravitystorm/openstreetmap-carto ?
>
> Merci, Vincent.
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>

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

Re: [Talk-ee] Eesti haldusjaotus

[Jaak Laineste]

Tervitus,

Äge! Vaadates vigade hulka (5876) on käsitsi nende järjest parandamine 
lootusetu, aga siit tuleb välja mõni huvitav muster, mida saaks skriptiga ka 
parandada. Näiteks:

Kas on ikkagi vaja küladele ja omavalitsustele ülemtasemete koode 
(EHAK:countycode ja EHAK:parishcode)? Nende EHAK koodide probleem on, et need 
muutuvad alati kui piirid muutuvad, ja praegu mitme maakonna (Läänemaa, 
Pärnumaa) piiride muutumisel on kõikide omavalisuste ja tuhandete külade 
maakonnakoodid aegunud. Ei saa ka lihtsalt neid uuendada, sest samal ajal läks 
suur osa külasid Läänemaalt Pärnumaale. Suur osa vigu praegu ongi vist sealt. 
Ettepanek: andmeliialdus lõpetada ja need ülemtasemete tagid lihtsalt 
eemaldada. Sisuliselt on see is_in tüüpi tag, mida saab andmete kasutaja 
asendada geograafilise sõltuvusega. Ehk siis jääb üks maakond ja sellel on 
EHAK:code, ja kui on vaja teada küla EHAK:countycode, siis saab selle 
geograafilise sisaldumise teel tuletada. Või veel OSM-ilikum oleks luua 
relatsioon, omavalisuste hierarhiatest, aga need kasvavad päris suureks ja 
oluliseks lisatööks, kui minna külade tasemeteni. Mis arvate? Tagi masseemaldus 
on suht lihtne, saab JOSM-iga juba ära teha, pole vaja skriptidagi.

Teine huvitav asi minu jaoks oleks muutunud külanimed (enim Saaremaal), ja neid 
saaks vähemalt leida, kui mitte kohe parandada. Kahjuks neid saab vist vaid 
geomeetria järgi leida, sest ümbernimetatud külal on minuteada ka uus EHAK 
kood. Praeguses rapordis on need olemas “has no OpenStreetMap relation”, aga 
neid on raske eristada, sest seal on paljud puudu muudel põhjustel. 
Geomeetriatega EHAK koodid saab Maaameti failidest 
(http://geoportaal.maaamet.ee/est/Andmed-ja-kaardid/Haldus-ja-asustusjaotus-p119.html).

Vaatan et Tormil on https://github.com/buildig/EHAK/tree/master/geojson 
 ka olemas geomeetriatega, 
ja GIT ajalugu võiks teoorias näidata ka diffe; neid on tekstipõhiselt ikkagi 
päris raske lugeda, aga ma ei teagi ühtegi head geo-diff vahendit,  mis näitaks 
graafiliselt geomeetriate/kaardi muutusi. Muide kui git-is oleks failid 
.geojson laiendiga siis github peaks oskama neid ka kuvada otse kaardil. 

Manuel, su skript ei ole githubis kasvõi gist-ina?

Jaak

> On 3 Jan 2018, at 00:00, Manuel Hohmann  
> wrote:
> 
> Tere ja head uut aastat!
> 
> Ma kirjutasin väikest skripti, mis tõmbab admin piire Eestis overpass APIst 
> ja EHAK andmeid siit et neid omavahel võrrelda:
> 
> https://github.com/buildig/EHAK/tree/master/csv
> 
> Täpsemalt see skript kontrollib:
> - Kas OSM relatsioonil on EHAK:code?
> - Kas EHAK:code on olemas / õige?
> - Kas EHAK:code on unikaalne (ainult ühel OSM relatsioonil)?
> - Kas OSM relatsioonil on sama nimi kui EHAK andmetes?
> - Kas OSM relatsioonil on sama admin level mida EHAK andmete järgi peaks 
> olema?
> - Kas OSM relatsioonil on sama EHAK:parishcode mida EHAK andmete järgi peaks 
> olema?
> - Kas OSM relatsioonil on sama EHAK:countycode mida EHAK andmete järgi peaks 
> olema?
> - Kas EHAK andmetes on asustused, mida OSMis ei ole?
> 
> Tulemus on kättesaadav siit ja uuendatakse öösiti kell 2:17 EEST:
> 
> http://mhohmann.dev.openstreetmap.org/eesti/haldus/haldus.txt
> 
> Praegune skript ei kontrolli geomeetriat.
> 
> Parimat,
> Manuel
> 
> PS: Alguses plaanisin selleks tööks oma "uut" serverit kasutada, mida ma 
> Avatud Maakaardi Seltsi käest sain, selleks et sellega panustada OSM'ile. Aga 
> tuli välja et see ülesanne on piisavalt lihtne, et see jookseb ka ilusasti 
> OSM arendajate serveri peal. Selle "uue" serveri peale tulevad siis mahukamad 
> OSM'iga seotud ülesanded :)
> 
> On 30.12.2017 20:25, Jaak Laineste wrote:
>> Tere ja head pühade jätku!
>> Haldusreformisin omavalitsuste tasemel lihtsamaid maakondi - Saaremaa, 
>> Hiiumaa ja Läänemaa sellepärast et neisse jäi mõnusalt vähe (1 või 3) 
>> omavalitsusi, ja Harjumaa sellepärast, et seal jäid enamus omavalitsusi 
>> samaks. Kuna iga maakonnaga tuli mõni huvitav erimoodi asi välja, siis 
>> “blogisin” enda tähelepanekuid siia: https://www.facebook.com/Maakaart 
>>  . Panin admin_level=7 neil, ja püüdsin 
>> EHAK-id õigeks panna, tundub et iga omavalitsuse muutusega muutub ka selle 
>> kood.
>> Külad on kontrollimata ja parandamata, ma oletan et Saaremaal peab olema 
>> õige mitu Rannaküla ümber nimetatud. Kuidas neid muudatusi üldse leida? 
>> Külasid on ikka paljuvõitu, täpsemalt 4708 tk, ükshaaval neid enam ei nopi.
>> Jaak
> 
> ___
> Talk-ee mailing list
> Talk-ee@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ee

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

[Talk-cz] Statistika využití CZ:IPRPraha:ortofoto

[Matej Lieskovský]

Ahoj!

Jak si možná vzpomínáte, před necelým rokem jsem pomohl získat povolení k
využití ortofotek IPR. Díky tomu nyní máme přístup k snímkům celé Prahy a
okolí, které jsou 2x ročně aktualizovány. V rámci dohody jsem slíbil
počítání statistik. Zatím čekám na zveřejnění nového planet.osm, ale tady
jsou statistiky k 25.12.:

Data IPR využilo 8 uživatelů ve 396 change setech, které se týkaly 46890
objektů.

Až budu mít zpracovaná novější data, tak bych jim tohle poslal jako součást
většího reportu.

Pokud proti tomu nikdo nic nemá, tak bych tam také použil frázi cca typu
"Dovolte, abych Vám jménem české komunity přispěvatelů do OSM poděkoval."

Taky bych tam rád napsal nějaká "pěkná" využití těch fotek. Překreslení
tramvajových tratí bylo z velké části pomocí IPR fotek, já jsem dělal pár
zlepšení porkytí parků (Valdštejná zahrada, Vojanovy sady, Malešický park,
Centrální park, Vyšehrad...), ale vykoukat další věci z těch changesetů je
trochu nad moje možnosti. Víte někdo o něčem, co by se dalo takhle
vypíchnout? Vím, že Piškvor toho taky udělal hodně, ale zatím nevím, jak to
pěkně popsat.

Ať se daří!

Matej

PS: Jo, snažím se dát IPR něco, co zní dobře. Oni to použijí jako
"podívejte se, jak je IPR užitečný" a výměnou za to nám snad do budoucna
dají více dat.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-it] disused:

[demon.box]

cascafico wrote
> Il building resta building=yes. É l'eventuale sua funzione che va in
> disuso: amenity, landuse, leisure ecc.

ok ma quindi se per esempio è semplicemente un'abitazione civile a non
essere più utilizzata non ho modo di indicarlo...

--enrico





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

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

Re: [Talk-it] disused:

[Cascafico Giovanni]

Il building resta building=yes. É l'eventuale sua funzione che va in
disuso: amenity, landuse, leisure ecc.
Per il rendering, se un riparo mimetico non é più utilizzabile, trovo
corretto che il suo rendering scompaia, cosa che non succederebbe con
disused=yes

Il 03/gen/2018 12:52, "demon.box"  ha scritto:

> ciao, vorrei sistemare (il mio) utilizzo non corretto del tag disused=yes
> visto che il wiki
>
> http://wiki.openstreetmap.org/wiki/IT:Key:disused:
>
> parla chiaro dicendo che è disincentivato a favore del prefisso disused:
>
> sono sincero che non ho ancora capito perchè sia disincentivato
>
> a parte il fatto che ad esempio nel caso di amenity=hunting_stand guardando
> taginfo
>
> trovo soltanto 11 volte disused:amenity=hunting_stand ... e mi sembra un
> po'
> pochino...
>
> ma a parte questo mi trovo in difficoltà quando ad esempio ho un edificio
> che palesemente non è più utilizzato ma non è nemmeno un rudere come
> faccio?
> non posso fare disused:building=yes perchè la caratteristica del building
> c'è ancora...
> stesso discorso per un building=industrial ...
> che dite?
> grazie
> --enrico
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-es] Cambio de logo para la comunidad OSM en España

[Javier Sánchez Portero]

Un dato en serio: El logo se está visualizando ahora mismo a 82x80 píxeles
y creo que debería tener siempre un tamaño algo menor que el de OSM
(160x160). Eso no da para muchas filigranas.

Y otro en broma: No estoy de acuerdo con usar el toro, prefiero rescatar la
gitanilla ahora que han desaparecido los televisores de tubo.

El 3 de enero de 2018, 11:49, dazer  escribió:

> Tiene el significado que quiera cada uno darle.
> Los logos no se supone que unan. Se supone que representan o identifican.
>
> En este caso identifica a un país; no a una comunidad de personas ni a un
> "pueblo". OSM representa realidades y conceptos. No sentimientos
> nacionales.
> La bandera es un concepto y una realidad identificable.
>
> La página de España, creo, no es para los españoles y sus sensibilidades,
> sino para coordinar los trabajos en España. Y eso implica que se pueda unir
> gente que no es de España; me parecería adecuado recibirles en un sitio que
> sea familar.
> Me parecería un error masivo no usar la bandera, independientemente de que
> a
> mi me gustase otro encaje territorial e institucional. Error porque la
> bandera es fácilmente reconocible e identificable dentro y, sobretodo,
> fuera
> de las fronteras. Es el símbolo que une con el resto del mundo.
>
> La opción de usar la figura del territorio (más Canarias, Baleares,
> ciudades
> autónomas, y plazas de soberanía menores) siempre se me ha antojado cutre:
> porque el territorio reconocible es la península (junto a Portugal), no la
> figura del país. Y peca de que en formatos pequeños, los territorios de la
> costa Africana no se ven (y merecen tanta representación como cualquier
> otro).
>
> Y ya medio jocoso, medio en serio: ya que otros países adoptan figuras
> folklóricas, estaría bien poner un toro de Osborne.
>
>
>
> --
> 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: [OSM-talk-fr] BANO / Cadastre différence nom de voie

[Christian Quest]

Sur le plan cadastral, il y a des libellés qui peuvent être différents de
ceux qu'on trouve dans FANTOIR... même si les deux sources sont la DGFiP.

Là, il n'y a que le terrain qui peut servir à départager ces incohérences.


Le 3 janvier 2018 à 13:16, Cyrille37 OSM  a
écrit :

> Salut
>
> Une différence d'orthographe pour le nom d'une rue:
> - dans BANO : Rue de H*u*ngerford
> - sur imagerie cadastre (JOSM) : Rue H*o*ngerford
> - lien osmose : http://osmose.openstreetmap.fr/fr/error/15045954115
>
> C'est étrange non ?
>
> Cyrille.
>
> ___
> 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] *** BULK *** Re: Contours des IRIS

[Christian Quest]

Le 3 janvier 2018 à 11:51, REBOUX Maël  a
écrit :

> Bonjour,
>
>
>
> Les IRIS sont un pis aller en terme de maillage statistique. Faute de
> mieux ils sont malheureusement encore trop utilisés. Ils sont de taille
> communale la plupart du temps et pas à jour ailleurs.
>


Ils ne sont réellement utiles que pour projeter des statistiques réalisées
par l'INSEE avec ce maillage, pour le reste, je ne vois pas trop.

Dans les quartiers où la population a changé, c'est sûr que ça ne
représente plus grand chose de significatif, y compris les stats si elles
n'ont pas été remises à jour par une enquête de terrain complète.


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

[OSM-talk-fr] BANO / Cadastre différence nom de voie

[Cyrille37 OSM]

Salut

Une différence d'orthographe pour le nom d'une rue:
- dans BANO : Rue de H*u*ngerford
- sur imagerie cadastre (JOSM) : Rue H*o*ngerford
- lien osmose : http://osmose.openstreetmap.fr/fr/error/15045954115

C'est étrange non ?

Cyrille.

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

Re: [Talk-es] Cambio de logo para la comunidad OSM en España

[dcapillae]

No hace falta ningún requisito previo para participar en la página de
discusión, sólo necesitarás crearte una cuenta en el wiki para poder
comentar. Respecto a participar en la votación, creo que tampoco hemos
puestos ningún requisito.

Comenta en cualquier caso, Miguel.



-
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-it] disused:

[demon.box]

ciao, vorrei sistemare (il mio) utilizzo non corretto del tag disused=yes
visto che il wiki

http://wiki.openstreetmap.org/wiki/IT:Key:disused:

parla chiaro dicendo che è disincentivato a favore del prefisso disused:

sono sincero che non ho ancora capito perchè sia disincentivato

a parte il fatto che ad esempio nel caso di amenity=hunting_stand guardando
taginfo

trovo soltanto 11 volte disused:amenity=hunting_stand ... e mi sembra un po'
pochino...

ma a parte questo mi trovo in difficoltà quando ad esempio ho un edificio
che palesemente non è più utilizzato ma non è nemmeno un rudere come faccio?
non posso fare disused:building=yes perchè la caratteristica del building
c'è ancora...
stesso discorso per un building=industrial ...
che dite?
grazie
--enrico



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

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

Re: [Talk-es] Cambio de logo para la comunidad OSM en España

[dazer]

Tiene el significado que quiera cada uno darle.
Los logos no se supone que unan. Se supone que representan o identifican.

En este caso identifica a un país; no a una comunidad de personas ni a un
"pueblo". OSM representa realidades y conceptos. No sentimientos nacionales.
La bandera es un concepto y una realidad identificable.

La página de España, creo, no es para los españoles y sus sensibilidades,
sino para coordinar los trabajos en España. Y eso implica que se pueda unir
gente que no es de España; me parecería adecuado recibirles en un sitio que
sea familar.
Me parecería un error masivo no usar la bandera, independientemente de que a
mi me gustase otro encaje territorial e institucional. Error porque la
bandera es fácilmente reconocible e identificable dentro y, sobretodo, fuera
de las fronteras. Es el símbolo que une con el resto del mundo.

La opción de usar la figura del territorio (más Canarias, Baleares, ciudades
autónomas, y plazas de soberanía menores) siempre se me ha antojado cutre:
porque el territorio reconocible es la península (junto a Portugal), no la
figura del país. Y peca de que en formatos pequeños, los territorios de la
costa Africana no se ven (y merecen tanta representación como cualquier
otro).

Y ya medio jocoso, medio en serio: ya que otros países adoptan figuras
folklóricas, estaría bien poner un toro de Osborne.



--
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-it] standardizzazione stradario comunale - civici fvg

[Andrea Musuruane]

Ciao Damjan,

2018-01-02 17:03 GMT+01:00 Damjan Gerl :

> Sono d'accordo con Andrea. Solamente che in FVG nell'importazione dei
> civici abbiamo scelto di usare il / come separatore per tutti i civici
> proprio per via dei tanti numeri con l'esponente numerico, ed il maiuscolo
> per le lettere. Cosa che poi va in conflitto con il "standard" nazionale
> scelto per osm: numero civico con gli esponenti senza separatore, e lettera
> dell'esponente minuscola.
>
> Ora come ora io i civici del FVG messi nuovi li converto nello standard
> usato per il FVG, però vorrei qui chiedere cosa ne pensate se sarebbe
> opportuno oppure no convertire tutti i numeri civici del fvg nello standard
> nazionale osm citato sopra, lasciando solamente i numeri con esponente
> numerico con il separatore / ?
>

Secondo me è una cosa da fare. Con la seguente query overpass, si possono
estrarre i civici da modificare. Sono circa 37 mila.
https://overpass-turbo.eu/s/uaM


Il FVG non è l'unica regione con questo problema. Quindi un workflow
replicabile sarebbe ovviamente apprezzato :-)

Però, prima di questo, bisognerebbe mettere mano alla wiki e documentare i
numeri civici e le specificità italiane.

Attualmente c'è solo una vecchia traduzione di Karlsruhe Schema.

La pagina principale sugli indirizzi è ancora da tradurre e, nella sezione
"Country specific rules and sources" manca una parte sull'Italia.
https://wiki.openstreetmap.org/wiki/Addresses

Recentemente ho aperto un bug su Street Complete per rimuovere la
possibilità di dare numeri civici agli edifici. Anche in questo caso, lo
sviluppatore mi chiede un riferimento aggiornato alla wiki.

Spero di mettere mano alla wiki al più presto. Ovviamente ogni aiuto è ben
accetto.

Nel frattempo aspetto qualche commento sulle modifiche fatte ai nomi delle
strade.

Ciao,

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

Re: [Talk-es] Cambio de logo para la comunidad OSM en España

[Miguel de Dios Matias]

Buenas.

Soy nuevo en el wiki. ¿Cómo va las reglas de las votaciones? Es como la
vieja wikipedia, hay que tener un mínimo de ediciones...

Saludos gracias.

El 3/1/2018 7:41, "dcapillae"  escribió:

> La bandera no tiene otro significado para mí, en este caso, que el que ya
> he
> expuesto. Por supuesto que una bandera tiene otras interpretaciones
> posibles, todos los símbolos las tienen, pero no creo que debamos entrar a
> discutir otras interpretaciones. La página del wiki para España necesita un
> logo. Los colores que identifican al país internacionalmente son los
> colores
> de la bandera española. España tiene un nombre y una bandera. Pues bien,
> usémoslos. Me parecen los más representativos. Diría lo mismo si fuese
> cualquier otro país.
>
> Respecto a las polémicas que suscita el uso de banderas, es una cuestión
> interesante. Podemos abordar el tema desde varios puntos de vistas. A mí me
> interesa particularmente la perspectiva antropológica del asunto, la
> cuestión de cómo se generan identidades colectivas a partir de una cultura
> compartida, pero no me parece una cuestión que debamos discutir en este
> foro.
>
> Por otro lado, que yo apoye el uso de los colores de la bandera española
> como símbolo más representativo del país no significa que me sienta
> políticamente representado por ella. Tampoco lo contrario. Simplemente es
> un
> tema en el que no voy a entrar.
>
> También es posible que estemos cayendo en una confusión. El logo que
> elijamos para la plantilla de la página del wiki no representa a la
> comunidad OSM española. Podemos tener un logo para la página del wiki, otro
> para la comunidad OSM española, otro para el capitulo local de OSM en
> España, otro para la Asociación OpenStreetMap España... Como comunidad de
> mapeadores podemos desvincularnos sin problemas del uso internacional de
> las
> banderas, pero para identificar un país, usar la bandera me parece
> correcto.
>
>
>
> -
> 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: [OSM-talk-fr] Corse et départements

[Christian Quest]

D’apres Wikipedia la CTC est équivalente à une région... mais avec un
statut un peu différent.

Le mer. 3 janv. 2018 à 10:29, Christian Quest  a
écrit :

> Encore un status bancal, comme la métropole de Lyon et le département du
> rhone...
>
> Si cette CTC chapeaute le 2A et le 2B, on peut la mettre en admin_level=5
> comme on a fait pour regrouper 69D et 69M... mais c'est quand même du
> bricolage administratif tout ça !
>
> Le 3 janvier 2018 à 10:17, Francescu GAROBY  a écrit :
>
>> Bonjour,
>> Avant de toucher aux 2 départements corses, j'aimerais qu'on me confirme
>> une chose : admin_level=6 désigne les départements, ou les conseils
>> départementaux ? Il me semblait que c'étaient les départements. De même que
>> admin_level=7 désigne les arrondissements.
>> Or, les 2 départements corses existent toujours, avec leurs préfectures
>> respectives. Ce sont les conseils départementaux qui ont disparu au
>> 01/01/2018, en fusionnant avec la CTC (l'équivalent d'un conseil régional,
>> pour faire simple).
>>
>> Bastia reste donc le chef-lieu du département de Haute-Corse, avec
>> toujours un préfet, mais plus de conseil départemental.
>>
>> Francescu
>>
>> Le 2 janvier 2018 à 23:17,  a écrit :
>>
>>> Bonjour,
>>>
>>> les départements 2A  et 2B
>>>  sont toujours en
>>> admin_level=6.
>>>
>>> N'est-ce pas plutôt :
>>> admin_level=6
>>> boundary:-2018=administrative
>>> boundary:2018-=historic
>>> boundary=historic
>>>
>>> Idem pour Bastia :
>>> admin_level=8
>>> admin_level:-2018=6
>>> admin_level:2018-=8
>>>
>>> (Ajaccio était et reste de niveau 4).
>>>
>>> Je suppose qu'un jour on reverra surgir les plaques d'immatriculation 20.
>>> Là La Poste a vu juste en conservant les codes 20xxx.
>>>
>>> Pour la Corse  (et la
>>> relation) :
>>> alt_name 
>>> =Collectivité
>>> territoriale de Corse
>>> Devient :
>>> alt_name=Collectivité de Corse
>>> alt_name:-2018=Collectivité territoriale de Corse
>>> alt_name:2018-=Collectivité de Corse
>>>
>>> Des erreurs ? Des omissions ?
>>>
>>> Jean-Yvon
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>>
>> --
>> Francescu
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Christian Quest - OpenStreetMap France
>
-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Fwd: Mapzen is shutting down.

[Roberto Brazzelli]

A poposito dei Mapzen e Mapbox mi sono trovato
ad utilizzarli entrambi per realizzare sfondo mappa web
però sono in difficoltà sull'utilizzare mapbox autodoor perchè
non aggiorna i dati da osm da parecchi mesi ..mentre su tangram
mi trovavo i fabbricati inseriti da con josm qualche mese fa.

Qualcuna sa come avviene l'aggiornameto di mapbox..ho provato a
scrivere ma ancora nessuna risposta da parecchio..grazie


Il 02/01/2018 19:36, Davide Sandona' ha scritto:
E' un vero peccato, negli anni avevano sviluppato molti progetti 
interessantissimi.
In ogni caso, il team che si occupa di Valhalla (un software di 
routing open source sviluppato da Mapzen) è appena stato "inglobato" 
da Mapbox:


**ANOUNCEMENT**: The Valhalla team is joining Mapbox where we'll
be taking Valhalla to the next level! Stay Tuned!! ** An Open
Source Routing Library/Service


[1] https://github.com/valhalla

 
	Virus-free. www.avast.com 
 




Davide.

2018-01-02 18:24 GMT+01:00 Federico Leva (Nemo) >:


O_o https://mapzen.com/blog/migration/


Questa non me l'aspettavo. La competizione ha decretato Mapbox
come vincitore?

Federico

 Messaggio inoltrato 
Oggetto:        Mapzen is shutting down.
Data:   Tue, 2 Jan 2018 17:20:25 +



Mapzen is shutting down.


  Mapzen is shutting down.

Unfortunately, we have some sad news. *Mapzen will cease
operations at the end of January 2018.* Our hosted APIs and all
related support and services will be shut down effective February
1, 2018. You will not be charged for API usage in December/January.

We know this is an inconvenience and have provided a migration
guide to similar services for our developer community. Our goal is
to help as much as possible to ensure continuity in the services
that you have built with us.

Fortunately, the core products of Mapzen are built entirely on
open software and data. As a result, there are options to run
Mapzen services yourself or to switch to other service providers.

Thanks for being with us over the past four years. We're grateful
that the open work we've done can continue outside of Mapzen and
while we know this is a sad day, we’re optimistic about what's next.

Thanks for being a Mapzen user,
Mapzen <3


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





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


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

Re: [OSM-talk-fr] *** BULK *** Re: Contours des IRIS

[REBOUX Maël]

Bonjour,

Les IRIS sont un pis aller en terme de maillage statistique. Faute de mieux ils 
sont malheureusement encore trop utilisés. Ils sont de taille communale la 
plupart du temps et pas à jour ailleurs.
Nous sommes un certain nombre de « grosses » collectivités territoriales à 
avoir réclamer à l’INSEE il y a déjà qqs années maintenant une mise à jour de 
ces limites, notamment dans les zones « dynamiques » (à l’urbanisation qui 
bouge vite et donc où la population croît). L’INSEE n’a pas accédé à nos 
demandes ce qui fait que ces maillages sont obsolètes sur les zones qui en 
auraient besoin.

Nous en sommes rendus à publier des mises à jour locales plus à jour des 
réalités du terrain. Exemple : 
https://public.sig.rennesmetropole.fr/geonetwork/srv/fre/catalog.search#/metadata/df789a3f-9980-4629-95be-50a8b04eac3c

Dans un souci de mise en adéquation des contours des différents zonages de 
gestion (quartier, périmètres électoraux...), Rennes Métropole a procédé à une 
numérisation des Iris en se basant sur des référentiels internes. Du fait de 
l'évolution des communes depuis la mise en œuvre des Iris, certains contours 
ont été revus en conséquence. De ce fait, cette couche n'est pas la couche 
officielle fournie par l'Insee (cf la description de la généalogie).

Cdt,

Maël REBOUX
Service Information Géographique Rennes Métropole
Chargé de mission "diffusion"
02 99 86 63 71
Twitter : @mael_reboux_ig

https://public.sig.rennesmetropole.fr   
|  https://data.rennesmetropole.fr


De : François Lacombe [mailto:fl.infosrese...@gmail.com]
Envoyé : samedi 30 décembre 2017 17:27
À : Discussions sur OSM en français
Objet : *** BULK *** Re: [OSM-talk-fr] Contours des IRIS

Bonjour
S'agissant en plus de contours basés sur des quantités de population, leurs 
limitent varient à certains endroits j'immagine ?
Les contours purement virtuels, qui n'ont pas plus d’interaction avec le reste 
des objets de la carte comme le bâti, les rivières, les infrastructures ont 
peut d'intérêt à se trouver véritablement dans OSM.
On ne va pas non plus favoriser leur correction par les contributeurs en les 
plaçant sur la carte.
Et je ne dis pas que ces données là n'ont pas d'intérêt, simplement qu'OSM ne 
va pas remplacer data.gouv
François

Le 30 décembre 2017 à 16:26, Christian Quest 
> a écrit :

De plus les contours IRIS en LO sont approximatifs, ceux précis, sont payants...

Le 29 décembre 2017 à 14:56, Cyrille37 OSM 
> a écrit :

Salut

Ça semble chouette d'avoir plus de données dans OSM, mais j'ai peur qu'il y a 
déjà énormément de mise à jour à suivre pour les éléments existants. Donc je 
pense que les IRIS sont très bien hors OSM et qu'il est facile pour qui sait 
faire des analyses, de les associés aux données OSM avec les outils adéquates.
C/.
Le 29/12/2017 à 13:56, Philippe Verdy a écrit :
De nombreuses cartes statistiques pourraient utiliser les délimitations 
infracommunales (les IRIS).
Elles sont libres (licence LO/OL).
Peut-on envisager de les importer (sachant qu'on a déjà une partie de ces 
contours pour les frontières communales, et les quartiers administratifs, et 
que ces IRIS sont aussi à la base de la délimitation du fractionnement cantonal 
qui s'appuie sur les statistiques fines de population calculées par IRIS).
Ce ne serait pas des frontières adminsitratives (boundary=administrative, mais 
statistiques (boundary=statistic). Et cela permettrait de recoller aussi avec 
le fractionnement cantonal des grandes communes.

On a ces données sur http://professionnels.ign.fr/contoursiris
(certes avec un tracé approximatif le long des rues, mais un tel import, ne 
concernant que les communes divisées en IRIS, pourrait dans un premier temps se 
faire sur des chemins séparés pour permettre ensuite une conflation avec les 
frontières communales ou de quartiers administratifs ou arrondissements 
municipaux).

Ces IRIS jouent un rôle important en terme de planification des projets publics 
et tout aussi important pour l'activité commerciale (zones de chalandises, 
études d'impact ou d'opportunité, etc) grace à la finesse des statistiques 
collectées par l'INSEE à ce niveau.

Peut-on créer un projet contenant une liste des communes subdivisées en IRIS 
avec un indicateur d'avancement (nombre d'IRIS à cartographier), éventuellement 
sur plusieurs sous-pages par département ou région ?

Que pensez vous du tag "boundary=statistic" (avec éventuellement un tag 
additionnel "admin_type:FR=iris" ou plutôt "border_type=FR:iris" puisque ce 
n'est pas strictement adminsitratif et qu'il n'y a pas de collectivité ou de 
personne morale associée à cette entité de découpage et d'aménagement 
territorial, très utile en France pour pouvoir représenter des tas de 
statistiques comme le propose déjà le 

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[Vincent Frison]

Le 3 janvier 2018 à 11:03, Vincent Frison  a
écrit :

> Bon visiblement l'absence de relief sur openstreetmap.org ne gêne pas
> grand monde mis à part moi :)
>
> Sinon je me rend compte que sur tile.openstreetmap.fr il y a une petite
> option pour afficher les hillshades d'openpistemap.org mais
> malheureusement ça ne marche pas. C'est sans doute lié au fait que le site
> openpistemap.org est lui même down ?
>

En fait j'ai l'impression que c'est l'ensemble des overlays qui déconnent
sur tile.openstreetmap.fr.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[Vincent Frison]

Bon visiblement l'absence de relief sur openstreetmap.org ne gêne pas grand
monde mis à part moi :)

Sinon je me rend compte que sur tile.openstreetmap.fr il y a une petite
option pour afficher les hillshades d'openpistemap.org mais malheureusement
ça ne marche pas. C'est sans doute lié au fait que le site openpistemap.org
est lui même down ?


Le 28 décembre 2017 à 15:10, Vincent Frison  a
écrit :

> Hello,
>
> Je sais pas si je suis le seul mais pour moi les cartes affichant le
> relief, c'est à dire avec hillshade et/ou courbes de niveaux, sont bien
> plus jolies que celles sont relief. Je dirais même qu'en plus d'être plus
> jolies elles sont beaucoup plus claires car elles permettent de se repérer
> plus facilement avec le relief.
>
> Le souci c'est que le rendu par défaut de osm.org n'a pas le relief et je
> trouve ça plus que dommage.
>
> Il y a des sites proposant des rendus avec reliefs qui sont magnifiques
> comme par ex. http://opentopomap.org ou http://opensnowmap.org. Le
> problème c'est qu'ils n'ont pas la rapidité d'osm.org, ni toutes ses
> fonctionnalités (principalement celle qui permet de chercher les objets
> afin de voir tous les détails).
>
> Certes il y a le layer "carte cyclable" d'osm.org mais malheureusement le
> relief est assez mal rendu et puis surtout il est vraiment orienté pour les
> vélos en masquant la plupart des informations pour mettre en valeur celles
> utiles aux cyclistes.
>
> J'ai l'impression que ça ne serait pas un énorme travail de rajouter le
> relief sur le rendu par défaut d'osm.org. L'idée serait d'avoir une
> option pour afficher le hillshade et les courbes de niveaux. c'est à dire 2
> petites checkboxes en plus de celles existantes (permettant d'afficher les
> notes de carte, etc.).
>
> Sur le site http://opensnowmap.org en allant dans les settings on peut
> afficher le rendu standard d'OSM au lieu de celui d'OpenSnow.  J'ai
> l'impression que c'est juste un layer supplémentaire (avec hillshade et
> courbes de niveaux) qui s'affiche en plus de celui du rendu standard.. mais
> qui du coup n'a plus rien à voir avec le rendu classique, pour moi la
> valeur ajoutée est vraiment énorme !
>
> Suis je le seul à qui ça manque ?
>
> Et à qui devrais  je demander cette évolution ? Sur un mailing list
> particulière ou directement en créant une issue ici: https://github.com/
> gravitystorm/openstreetmap-carto ?
>
> Merci, Vincent.
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[Christian Quest]

Rendu vectoriel... et mapcat est un très bel exemple de ce qu'on peut faire
avec les données OSM + wikipédia.

Le 3 janvier 2018 à 10:40, Bruno  a écrit :

> Le 03/01/2018 à 10:25, Marc Gemis a écrit :
>
>> Connaissez-vous https://www.mapcat.com ?
>> - OSM data
>> - clic gauche
>> - des noms en langue locale et Anglais.
>>
>> m.
>>
> Je ne connaissais pas.
> Pour le changement de langue et vu le choix important, j'imagine qu'il n'y
> a pas un rendu par langage ? c'est quoi le mécanisme technique ?
>
> 2018-01-02 23:32 GMT+01:00 marc marc :
>>
>>> Bonsoir,
>>>
>>> Le 02. 01. 18 à 23:10, Cédric Frayssinet a écrit :
>>>
 Quand on passe de GMaps à OpenStreetMap.org, je trouve que l'on perd
 beaucoup à ne pas pouvoir cliquer (avec le bouton gauche)

>>> il est clair qu'un clic droit serrait beaucoup pratique et intuitif.
>>>
>>> - interroger les objets

>>> petit raccourcit : afficher l'adresse
>>> cela ne te propose souvent le bon objet.
>>>
>>> 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
>>
>
>
>
> ___
> 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] Ergonomie d'OpenStreetMap.org

[Bruno]

Le 03/01/2018 à 10:25, Marc Gemis a écrit :

Connaissez-vous https://www.mapcat.com ?
- OSM data
- clic gauche
- des noms en langue locale et Anglais.

m.

Je ne connaissais pas.
Pour le changement de langue et vu le choix important, j'imagine qu'il 
n'y a pas un rendu par langage ? c'est quoi le mécanisme technique ?

2018-01-02 23:32 GMT+01:00 marc marc :

Bonsoir,

Le 02. 01. 18 à 23:10, Cédric Frayssinet a écrit :

Quand on passe de GMaps à OpenStreetMap.org, je trouve que l'on perd
beaucoup à ne pas pouvoir cliquer (avec le bouton gauche)

il est clair qu'un clic droit serrait beaucoup pratique et intuitif.


- interroger les objets

petit raccourcit : afficher l'adresse
cela ne te propose souvent le bon objet.

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




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

Re: [OSM-talk-fr] Corse et départements

[Christian Quest]

Encore un status bancal, comme la métropole de Lyon et le département du
rhone...

Si cette CTC chapeaute le 2A et le 2B, on peut la mettre en admin_level=5
comme on a fait pour regrouper 69D et 69M... mais c'est quand même du
bricolage administratif tout ça !

Le 3 janvier 2018 à 10:17, Francescu GAROBY  a écrit :

> Bonjour,
> Avant de toucher aux 2 départements corses, j'aimerais qu'on me confirme
> une chose : admin_level=6 désigne les départements, ou les conseils
> départementaux ? Il me semblait que c'étaient les départements. De même que
> admin_level=7 désigne les arrondissements.
> Or, les 2 départements corses existent toujours, avec leurs préfectures
> respectives. Ce sont les conseils départementaux qui ont disparu au
> 01/01/2018, en fusionnant avec la CTC (l'équivalent d'un conseil régional,
> pour faire simple).
>
> Bastia reste donc le chef-lieu du département de Haute-Corse, avec
> toujours un préfet, mais plus de conseil départemental.
>
> Francescu
>
> Le 2 janvier 2018 à 23:17,  a écrit :
>
>> Bonjour,
>>
>> les départements 2A  et 2B
>>  sont toujours en
>> admin_level=6.
>>
>> N'est-ce pas plutôt :
>> admin_level=6
>> boundary:-2018=administrative
>> boundary:2018-=historic
>> boundary=historic
>>
>> Idem pour Bastia :
>> admin_level=8
>> admin_level:-2018=6
>> admin_level:2018-=8
>>
>> (Ajaccio était et reste de niveau 4).
>>
>> Je suppose qu'un jour on reverra surgir les plaques d'immatriculation 20.
>> Là La Poste a vu juste en conservant les codes 20xxx.
>>
>> Pour la Corse  (et la
>> relation) :
>> alt_name 
>> =Collectivité
>> territoriale de Corse
>> Devient :
>> alt_name=Collectivité de Corse
>> alt_name:-2018=Collectivité territoriale de Corse
>> alt_name:2018-=Collectivité de Corse
>>
>> Des erreurs ? Des omissions ?
>>
>> Jean-Yvon
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Francescu
>
> ___
> 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: [Talk-es] Importación de Catastro

[dcapillae]

Málaga municipio. Casi todas mis ediciones son a nivel municipal.

Voy ampliando la página del wiki dedicada a Málaga conforme voy tocando
diversas temáticas: transporte público, cultura, etc. La página me sirve
para anotar los progresos, pero también para animar a otros contribuidores
de la zona a participar en la mejora del mapa a nivel municipal, en los
temas que más les interesen.

http://wiki.openstreetmap.org/wiki/ES:Málaga

De momento no he puesto nada sobre la importación de edificios, pero en
cuanto tengamos permiso para hacer importaciones y comencemos a trabajar con
el gestor de tareas, tengo intención de abrir una nueva sección en la página
del wiki desde la que animar a otros contribuidores a participar. Vamos a
necesitar mucha colaboración.





-
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: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[Marc Gemis]

Connaissez-vous https://www.mapcat.com ?
- OSM data
- clic gauche
- des noms en langue locale et Anglais.

m.

2018-01-02 23:32 GMT+01:00 marc marc :
> Bonsoir,
>
> Le 02. 01. 18 à 23:10, Cédric Frayssinet a écrit :
>> Quand on passe de GMaps à OpenStreetMap.org, je trouve que l'on perd
>> beaucoup à ne pas pouvoir cliquer (avec le bouton gauche)
>
> il est clair qu'un clic droit serrait beaucoup pratique et intuitif.
>
>> - interroger les objets
> petit raccourcit : afficher l'adresse
> cela ne te propose souvent le bon objet.
>
> 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] Ergonomie d'OpenStreetMap.org

[Bruno]

Le 03/01/2018 à 10:10, Lionel Allorge a écrit :

Bonjour,


Pour ma part j'en ai un autre qui n'est pas qu'un problème d'ergonomie :

La carte est affichée dans la langue du pays par défaut, si je regarde
la Russie ou la Pologne , et bien c'est inutilisable (pour moi)

J'ai eu le même problème et j'utilise depuis :
http://tile.openstreetmap.fr/
qui propose les noms en français lorsqu'ils existent.

Librement.

Oui je suis d'accord, c'est ce que je fais aussi et j'aurai du le dire, 
mais comme on parlait d'ergonomie et de simplicité d'emploi je trouve 
que dire aux gens tu vas sur osm.org c'est plus simple que 
"tile.openstreetmap.org".


Dommage osm.fr est déjà pris..

Bruno


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

Re: [OSM-talk-fr] Corse et départements

[Francescu GAROBY]

Bonjour,
Avant de toucher aux 2 départements corses, j'aimerais qu'on me confirme
une chose : admin_level=6 désigne les départements, ou les conseils
départementaux ? Il me semblait que c'étaient les départements. De même que
admin_level=7 désigne les arrondissements.
Or, les 2 départements corses existent toujours, avec leurs préfectures
respectives. Ce sont les conseils départementaux qui ont disparu au
01/01/2018, en fusionnant avec la CTC (l'équivalent d'un conseil régional,
pour faire simple).

Bastia reste donc le chef-lieu du département de Haute-Corse, avec toujours
un préfet, mais plus de conseil départemental.

Francescu

Le 2 janvier 2018 à 23:17,  a écrit :

> Bonjour,
>
> les départements 2A  et 2B
>  sont toujours en
> admin_level=6.
>
> N'est-ce pas plutôt :
> admin_level=6
> boundary:-2018=administrative
> boundary:2018-=historic
> boundary=historic
>
> Idem pour Bastia :
> admin_level=8
> admin_level:-2018=6
> admin_level:2018-=8
>
> (Ajaccio était et reste de niveau 4).
>
> Je suppose qu'un jour on reverra surgir les plaques d'immatriculation 20.
> Là La Poste a vu juste en conservant les codes 20xxx.
>
> Pour la Corse  (et la
> relation) :
> alt_name 
> =Collectivité
> territoriale de Corse
> Devient :
> alt_name=Collectivité de Corse
> alt_name:-2018=Collectivité territoriale de Corse
> alt_name:2018-=Collectivité de Corse
>
> Des erreurs ? Des omissions ?
>
> Jean-Yvon
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[Jo]

le rendu standard de openstreetmap.org n'est pas là pour être "utilisable"
ni ergonomique, il est là pour les éditeurs pour vérifier ce qu'ils/elles
font.

Pour un rendu POI il faut d'autres solutions et OSM devrait y renvoyer.

Polyglot

2018-01-03 10:01 GMT+01:00 Stéphane Péneau :

> Le 03/01/2018 à 09:55, Bruno a écrit :
>
>>
>> La carte est affichée dans la langue du pays par défaut, si je regarde la
>> Russie ou la Pologne , et bien c'est inutilisable (pour moi)
>>
>> Osm.org devrait afficher la carte en prenant en compte la langue du
>> navigateur.
>>
>> Techniquement, et pour le moment, ça demande un rendu différent par
> langue. C'est beaucoup trop pour une petite "structure" tel que
> OpenStreetMap.
>
> Stf
>
>
> ___
> 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] Ergonomie d'OpenStreetMap.org

[Lionel Allorge]

Bonjour,

> Pour ma part j'en ai un autre qui n'est pas qu'un problème d'ergonomie :
> 
> La carte est affichée dans la langue du pays par défaut, si je regarde
> la Russie ou la Pologne , et bien c'est inutilisable (pour moi)

J'ai eu le même problème et j'utilise depuis :
http://tile.openstreetmap.fr/
qui propose les noms en français lorsqu'ils existent.

Librement.

-- 
Lionel Allorge
April : http://www.april.org
Lune Rouge : http://www.lunerouge.org
Wikimedia France : http://wikimedia.fr
OpenStreetMap France : http://www.openstreetmap.fr/

« Bien informés, les hommes sont des citoyens;
mal informés ils deviennent des sujets. »
Alfred Sauvy

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

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[Stéphane Péneau]

Le 03/01/2018 à 09:55, Bruno a écrit :


La carte est affichée dans la langue du pays par défaut, si je regarde 
la Russie ou la Pologne , et bien c'est inutilisable (pour moi)


Osm.org devrait afficher la carte en prenant en compte la langue du 
navigateur.


Techniquement, et pour le moment, ça demande un rendu différent par 
langue. C'est beaucoup trop pour une petite "structure" tel que 
OpenStreetMap.


Stf

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

Re: [Talk-es] Importación de Catastro

[Javier Sánchez Portero]

Genial.

Veo que tienes muchos edificios dibujados. Puedes empezar por las zonas en
las que no hay edificios y dejar para el final añadirle las direcciones y
partes (si quieres mapeo 3D) a los edificios que ya están dibujados.

Una pregunta, ¿Málaga ciudad, municipio o provincia?

Yo me ofrezco voluntario a gestionar la provincia de Santa Cruz de Tenerife.


El 3 de enero de 2018, 7:34, dcapillae  escribió:

> Me ofrezco voluntario para gestionar el proyecto de importación de
> edificios
> en Málaga cuando se ponga en marcha. Nunca he gestionado un proyecto en el
> gestor de tareas. He participado como colaborador resolviendo algunas
> tareas
> para proyectos del HOT, pero nunca he gestionado ninguno.
>
> No me preocupa si el volumen de tareas es elevado. Mapear todos los
> edificios de Málaga es algo que me había propuesto hace tiempo y para lo
> que
> he contado con la colaboración de otros mapeadores. No me importaría
> encargarme personalmente de gestionar el proyecto cuando se ponga en
> marcha.
> Tengo particular interés en que salga bien:
> http://www.openstreetmap.org/user/dcapillae/diary/41229
>
> Este fin de semana espero tener terminada la validación del proceso de
> conversión. Subiré los resultados al wiki cuando los tenga.
>
>
>
> -
> 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: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[Bruno]

Le 02/01/2018 à 23:10, Cédric Frayssinet a écrit :


Bonsoir à tous,

Je vais peut-être lancer un pavé dans la mare, mais je me lance :)

Quand on passe de GMaps à OpenStreetMap.org, je trouve que l'on perd 
beaucoup à ne pas pouvoir cliquer (avec le bouton gauche) sur les 
nœuds, type commerces, restaurants ou attractions touristiques. C'est 
vraiment dommage car souvent les tags nécessaires y sont. Avec Gmaps, 
on clique puis on affiche un volet complet qui permet ce que vous savez.


Suis je le seul à trouver le menu contextuel peu pratique ?

- interroger les objets

- puis sélectionner ce que l'on souhaite dans la liste qui s'affiche 
dans le volet latéral


Je ne sais pas comment sont gérés ces travaux de développement, c'est 
pourquoi j'interroge la liste...


Bonne soirée,

Cédric


--
En cure de désintoxication  de 
Google ! Client d'Enercoop 
, l'énergie militante


Également sur Mastodon : @bristow...@framapiaf.org 



Promouvoir et soutenir le logiciel libre 



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


Bonjour,

Oui clairement il n'y a rien de très ergonomique ou même simplement 
fonctionnel pour interroger des POI sur la carte, à l'heure actuelle.


Les astuces comme passer par une recherche d'adresse ou la fonction 
requêter des objets  sont utilisables mais pas du même niveau.
Je ne sais pas non plus ou intervenir pour remonter ce genre de besoin , 
qui ne doit pas être nouveau..


Pour ma part j'en ai un autre qui n'est pas qu'un problème d'ergonomie :

La carte est affichée dans la langue du pays par défaut, si je regarde 
la Russie ou la Pologne , et bien c'est inutilisable (pour moi)


Osm.org devrait afficher la carte en prenant en compte la langue du 
navigateur.


Bruno.


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

Re: [OSM-talk-fr] Tagguer les cinémas "art & essai"

[Antoine Riche]

En anglais on parle de "arts cinema" 
(https://en.wikipedia.org/wiki/International_Confederation_of_Art_Cinemas), 
on pourrait utiliser arts=yes ou plus explicite arts_cinema=yes.


Il y a un numéro d'autorisation dans le fichier open data, on le met en 
ref:FR:CNC ?


De nombreuses salles Arts et Essai en Europe sont membres du réseau 
Europa Cinemas (http://www.europa-cinemas.org/), tant qu'à y être on 
pourrait les identifier avec brand=Europa Cinemas


Ce qui donne (pour les zélés) :
arts_cinema=yes (toute salle se réclamant Arts et Essai, avec ou sans 
label selon les pays)

ref:FR:CNC=
cinema:FR:art_essai=A|B|C|D|E  (salles classés par le CNC)
brand=Europa Cinemas (pour les salles du réseau)

La valeur no pour cinema:FR:art_essai ne me semble plus utile si on 
applique les autres tags, on aurait plutôt arts_cinema=no


Antoine.

Le 02/01/2018 à 23:24, marc marc a écrit :

Le 02. 01. 18 à 22:57, osm.sanspourr...@spamgourmet.com a écrit :

Le 02/01/2018 à 21:10, George Kaplan - georgekaplan...@hotmail.fr a écrit :

De façon similaire à school:FR, ça donne plutôt cinema:FR=art_essai .
Est-ce qu’il y a un terme du CNC pour les cinémas qui ne sont pas
« art et essai » ?


Oui, c'est dans la liste citée et ça s'appelle "NON";-).
Je propose simplement :
cinema:FR:art_essai=A|B|C|D|E|no

étant donné que chaque cinéma est susceptible de diffuser ce genre de
film, ne serrait-il pas intéressant d'essayer de trouver un nom de tag
anglais "parent" qui puisse s'appliquer "mondialement" sous la forme
cinema: =yes/no ?

avoir un tag commun permet un jour d'avoir un outil qui permet de
trouver un tel cinéma peu importe s'il se trouve à Roubais ou à Mons.

cela n’empêche pas d'avoir un tag :FR pour l'affinage de la
classification niveau français mais qui irait dans un sous-tag du tag
avec le mot anglais comme c'est la tradition dans osm.
par analogie, on utilise school:FR et non pas ecole:FR
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr





---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[David Crochet]

Bonjour


Le 03/01/2018 à 08:57, David Crochet a écrit :

sur la gauche pour cela


Droite, je voulais dire droite.

Cordialement

--
David Crochet


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