Re: [talk-au] Legal access to Public land ...

[Warin]

On 7/7/2016 12:35 PM, fors...@ozonline.com.au wrote:

Hi

Even with Warin's proposed edit to the wiki guidelines, I think it is 
still unclear whether its better to use the value 'private' or 'no' 
for the 'access' key. (And the various transport mode keys).


For example, for tracks in national parks and closed water catchments 
which have more restrictive conditions for the general public than 
they do for the managing bodies, such as:'Management vehicles and 
walkers only'.


The guidelines http://wiki.openstreetmap.org/wiki/Key:access#Values
'no' No access for the general public
seems to me to mean much the same as
'private' Only with permission of the owner on an individual basis

Maybe some specific examples in the wiki might help clarify this?


The Australian guide should be Australian specific .. not used to give 
what is a detailed general explanation of a key/value.


access tags - as I see it

yes - full legal, access at any time. I would expect general traffic here.
permissive - open access at present. Maybe withdrawn by the owner. I 
would expect general traffic.
discouraged - access is discouraged but available. I would expect 
reduced traffic.
private - access with the permission of the owner. I would expect little 
traffic, only official vehicles or property owners.
no - no access to the general public. I would expect very little to no 
traffic.


activity types of access
delivery - only vehicles making delivery.
destination - only vehicles stopping in the locality
customer - only vehicles shopping here
designated  - only vehicles meeting the type of vehicle stated
agricultural - only agricultural vehicles (tractors, combine harvesters etc)
forestry - only forestry vehicles (e.g. timber jinkers)
dismount - for cyclists

With access=no I would not expect to be able to apply for access, for 
access=private I would expect to be able to apply for access (but not 
necessarily get it).


For "Management vehicles and walkers only" I would use
access=no
foot=yes

As that means - walkers can use it - no restriction.
General public (other than walkers (foot)) have no access. This excludes 
cyclist, horse riders etc etc. If there were lots of management vehicles 
using it I might add motor_vehicle=private.


There are lots of different access restrictions existing in Australia .. 
but they also exist around the world .. so nothing specific to Australia?






Tony


On 7/5/2016 9:13 AM, Mark Pulley wrote:

On 2 Jul 2016, at 3:30 pm, Warin <61sundow...@gmail.com> wrote:


On 7/2/2016 9:26 AM, Frank wrote:

OpenStreetMap Wiki page Australian Tagging Guidelines has been
changed on 1 July 2016 by Swanilli to say that the public has a  
legal right to access public land ...


No!

The NSW NPSW do legally exclude the public from certain areas and 
 at least vehicles from certain tracks.


The NSW, WA, SA and Victorian State Forests legally exclude the  
public too .. think about the car rallies held from time to time.


Even 'public roads' get closed to the public from time to time... 
 how else would the Bathurst Road Race be held?


I have remove the offending statement from the wiki. I did  
attempt to contact the user .. but the wiki page has no send a  
message' type thiny ...  hence this message.

Found the contact ... made comments on 2 changesets.
Confusion may have arisen over plain English understanding of
access=no

But the tags are
access=no
foot=yes

meaning you can access by foot but nothing else... in the OSM data 
base.


I have been using

motor_vehicle=no (or motorcar=no / motorcycle=no)
foot=yes (or foot=designated)

and depending on other tags

bicycle=no (or bicycle=designated if specifically signposted)

Mark P.



Thanks Mark. That is a good method...

I'd use motor_vehicle as that covers trucks, tractors etc.

On review I think something for the Oz wiki tagging guide lines page
http://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines#Access_roads_on_public_land 
along the  lines

of

"Where an access road crosses public land it should not be assumed to
have or not have access restrictions. Where a sign says "Authorised
vehicles Only" or you know that access is restricted the tag
motor_vehicle=private could be used to indicate the access restriction.
Access restrictions for others (walkers, cyclists etc.) should be found
on the access wiki page (link to
http://wiki.openstreetmap.org/wiki/Key:access).
To help other mappers recognise the validity of the access restriction
a sourec tag can be used e.g. source:access_motor_vehicle=sign on
eastern end of road"

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

_
This mail has been virus scanned by Australia On Line
see http://www.australiaonline.net.au/mailscanning









___
Talk-au mailing list
Talk-au@openstreetmap.org

Re: [Talk-it] import civici Emilia Romagna

[Alessandro Palmas]

Il 06/07/2016 23:54, Gianmario Mengozzi ha scritto:


Ocio che in alcune provincie / comuni l'import dei civici era già 
stato fatto. In quei casi che si fa?




Sentiamo qualche esperto, IMHO farei un certo numero di controlli a campione

Alessandro Ale_Zena_IT

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

Re: [OSM-talk] School project Ghana

[Eduardo A. Mayorga]

I think the materials available in http://learnosm.org/en/ would be
situable.

Eduardo

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

Re: [talk-au] Legal access to Public land ...

[forster]

Hi

Even with Warin's proposed edit to the wiki guidelines, I think it is  
still unclear whether its better to use the value 'private' or 'no'  
for the 'access' key. (And the various transport mode keys).


For example, for tracks in national parks and closed water catchments  
which have more restrictive conditions for the general public than  
they do for the managing bodies, such as:'Management vehicles and  
walkers only'.


The guidelines http://wiki.openstreetmap.org/wiki/Key:access#Values
'no'No access for the general public
seems to me to mean much the same as
'private' Only with permission of the owner on an individual basis

Maybe some specific examples in the wiki might help clarify this?

Tony


On 7/5/2016 9:13 AM, Mark Pulley wrote:

On 2 Jul 2016, at 3:30 pm, Warin <61sundow...@gmail.com> wrote:


On 7/2/2016 9:26 AM, Frank wrote:

OpenStreetMap Wiki page Australian Tagging Guidelines has been
changed on 1 July 2016 by Swanilli to say that the public has a   
legal right to access public land ...


No!

The NSW NPSW do legally exclude the public from certain areas and  
 at least vehicles from certain tracks.


The NSW, WA, SA and Victorian State Forests legally exclude the   
public too .. think about the car rallies held from time to time.


Even 'public roads' get closed to the public from time to time...  
 how else would the Bathurst Road Race be held?


I have remove the offending statement from the wiki. I did   
attempt to contact the user .. but the wiki page has no send a   
message' type thiny ...  hence this message.

Found the contact ... made comments on 2 changesets.
Confusion may have arisen over plain English understanding of
access=no

But the tags are
access=no
foot=yes

meaning you can access by foot but nothing else... in the OSM data base.


I have been using

motor_vehicle=no (or motorcar=no / motorcycle=no)
foot=yes (or foot=designated)

and depending on other tags

bicycle=no (or bicycle=designated if specifically signposted)

Mark P.



Thanks Mark. That is a good method...

I'd use motor_vehicle as that covers trucks, tractors etc.

On review I think something for the Oz wiki tagging guide lines page
http://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines#Access_roads_on_public_land  along the   
lines

of

"Where an access road crosses public land it should not be assumed to
have or not have access restrictions. Where a sign says "Authorised
vehicles Only" or you know that access is restricted the tag
motor_vehicle=private could be used to indicate the access restriction.
Access restrictions for others (walkers, cyclists etc.) should be found
on the access wiki page (link to
http://wiki.openstreetmap.org/wiki/Key:access).
To help other mappers recognise the validity of the access restriction
a sourec tag can be used e.g. source:access_motor_vehicle=sign on
eastern end of road"

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

_
This mail has been virus scanned by Australia On Line
see http://www.australiaonline.net.au/mailscanning






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

Re: [Talk-GB] Removal of "sport" from recreation grounds, adding fixmes (was sport=soccer not sport=football.)

[Warin]

On 7/7/2016 10:32 AM, Warin wrote:

On 6/13/2016 5:55 PM, Andy Townsend wrote:
As a bit more background to this, see the changeset discussion 
comments on https://www.openstreetmap.org/changeset/39809705 and 
https://www.openstreetmap.org/changeset/39812846 .  I got a reply re 
"football vs soccer", but not about any of the other questions raised 
in there. 


Football.
Ok. No dissension on sport=football to sport= soccer ... if I can 
identify it from bing imagery.

Where I cannot identify it I am inclined to leave a fixme tag on it.


As for the other things ...
Court/pitch separation.
For example way 422897831 ... from bing. There is a faint outline of 
what to me is a netball court. So I added that.


I am inclined to separate individual sport courts .. so there is a 
overlay of a tennis court there too.. Some courts are head to tail 
aligned as here, others are, for example, 4 tennis courts and 3 
netball courts .. thus the individual mapping allows for visual 
identification of this. Also some courts run across the other courts - 
one set north to south the others east to west. I think the added 
detail is better than numerical tags as these separate courts render 
without any additional requirements, make it clear as to the number 
and orientation of the courts. It is more work but easy to do and has 
some benefit.


Also .. by separating the sport/pitch you can make seasonal attributions 
for example: sport=cricket, seasonal=spring;summer with another overlay 
pitch sport=soccer, seasonal=autumn;winter




Field_hockey.
Hummm yes well ... I am not familiar with soccer other than the 11 a 
side one (which I played on many Saturdays in a club). I think some of 
the 'smaller' games look to me very much like field hockey markings ? 
It would help if there were tags to identify these ... for example 
sport=soccer, soccer:5_a_side:yes, soccer:minisoccer=yes But I think 
more urgent would be some documentation on the wiki (both soccer and 
field_hockey)?


Sports on Recreation Grounds ...
 I prefer to map the individual pitches as this gives the orientation, 
location and number of pitches. While some of these may move from 
season to season they don't usually move far due to size restrictions, 
nor do the number of pitches change. I don't map 'social games' that 
have no on ground infrastructure .. for example a game of football on 
a grassed area I don't map it as a pitch... no sidelines, goal posts 
etc .. just jumpers on the ground as markers for goals, corners ...

So putting sports on recreation grounds to me .. I don't do.

--
Future activity for me + sport?
Apart from sport=football there are sport=hockey (probably to 
sport=field_hockey where identified by bing imagery) and sport=multi 
(sport=x;multi where x is the sport identified by bing imagery) .. 
these are all possibilities. The one with the most impact would be 
sport=multi followed by sport=hockey.







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

Re: [Talk-GB] Removal of "sport" from recreation grounds, adding fixmes (was sport=soccer not sport=football.)

[Warin]

On 6/13/2016 5:55 PM, Andy Townsend wrote:
As a bit more background to this, see the changeset discussion 
comments on https://www.openstreetmap.org/changeset/39809705 and 
https://www.openstreetmap.org/changeset/39812846 .  I got a reply re 
"football vs soccer", but not about any of the other questions raised 
in there. 


Football.
Ok. No dissension on sport=football to sport= soccer ... if I can 
identify it from bing imagery.

Where I cannot identify it I am inclined to leave a fixme tag on it.


As for the other things ...
Court/pitch separation.
For example way 422897831 ... from bing. There is a faint outline of 
what to me is a netball court. So I added that.


I am inclined to separate individual sport courts .. so there is a 
overlay of a tennis court there too.. Some courts are head to tail 
aligned as here, others are, for example, 4 tennis courts and 3 netball 
courts .. thus the individual mapping allows for visual identification 
of this. Also some courts run across the other courts - one set north to 
south the others east to west. I think the added detail is better than 
numerical tags as these separate courts render without any additional 
requirements, make it clear as to the number and orientation of the 
courts. It is more work but easy to do and has some benefit.


Field_hockey.
Hummm yes well ... I am not familiar with soccer other than the 11 a 
side one (which I played on many Saturdays in a club). I think some of 
the 'smaller' games look to me very much like field hockey markings ? It 
would help if there were tags to identify these ... for example 
sport=soccer, soccer:5_a_side:yes, soccer:minisoccer=yes But I think 
more urgent would be some documentation on the wiki (both soccer and 
field_hockey)?


Sports on Recreation Grounds ...
 I prefer to map the individual pitches as this gives the orientation, 
location and number of pitches. While some of these may move from season 
to season they don't usually move far due to size restrictions, nor do 
the number of pitches change. I don't map 'social games' that have no on 
ground infrastructure .. for example a game of football on a grassed 
area I don't map it as a pitch... no sidelines, goal posts etc .. just 
jumpers on the ground as markers for goals, corners ...

So putting sports on recreation grounds to me .. I don't do.

--
Future activity for me + sport?
Apart from sport=football there are sport=hockey (probably to 
sport=field_hockey where identified by bing imagery) and sport=multi 
(sport=x;multi where x is the sport identified by bing imagery) .. these 
are all possibilities. The one with the most impact would be sport=multi 
followed by sport=hockey.




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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[Jérôme Amagat]

Le 6 juillet 2016 à 22:19, François Lacombe  a
écrit :

> Le 6 juillet 2016 à 20:03, Jérôme Amagat  a
> écrit :
>>
>>
>> Ce que je voulais dire par cette ajout c’était pour différencié route
>> dans le sens de la chaussée comme tu le dis et route, un itinéraire. Si tu
>> te place n'importe où de la chaussée de la D31, tu peux dire que tu es sur
>> la D31. par contre quelqu'un a pied sur l'itineraire du bus de la ligne L6
>> il ne dira jamais qu'il es sur la la L6.
>>
> Ça serait valable si en "ville" "les gens" savaient encore où passent les
> départementales. Et vu qu'en "ville", "les gens" utilisent les noms de rue,
> on ne doit pas mettre D xx mais le nom de la rue ?
>
> Il pourrait aussi dire qu'il est sur l'itinéraire bis numéro 2, sur
> l'itinéraire spécial 34 ou bien sur la route des convois exceptionnel
>
Comment ça vous ne le dites pas vous ?
>
quelqu'un dit qu'il est sur l'itineraire bis quand il utilise cette
itineraire comme itineraire bis. Si tu ne parle pas de convois exceptionel
personne ne se dira sur la route des convois exceptionnel. pour tout ces
truc comme pour les transports en commun, il y a le lieu et autre chose :
le type de transport, la destination... Alors que pour les routes
départementales seul le lieu importe.

>
> Enfin, chacun appelle sa route comme il le souhaite, c'est aussi un
> avantage des relations : on se partage tous le même chemin, mais on ne
> l’appelle pas de la même façon.
> Où il est écrit que le bout de route doit comporter la référence de
> l'itinéraire le plus connu qui passe dessus ? (et encore, le plus connu ça
> reste à démontrer).
>
>
>
>>
>> D31 c'est pas un itinéraire c'est une route c'est du concret.
>>
> Pas pour tous en tout cas, certains centres d'exploitation n'utilisent pas
> les numéros de départementale mais des numéros de section de chaussée.
>
>
>> Une maison non plus n'est pas un objet physique, le mur en parpaing oui
>> la charpente, la porte et c'est parce qu’on le décide que cette ensemble
>> est une maison.
>>
>
> Tu vas te heurter au problème de l'échelle, est-ce réalisable de dessiner
> la charpente sous josm ?
> Dessiner plein de bout de route, y compris les obstacles, ronds point et
> autre oui.
>

tu te plais quand je me sers des tag de osm comme argument mais toi tu te
sers de l'echelle de osm.
C’était un exemple pour montrer que tout le monde pouvait jouer sur les
mots comme tu le fais quand tu utilise la chaussée comme élément de base.

>
>
> François
>
>
> ___
> 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] Tag 'network' et 'name' pour une relation de type route départementale

[Christian Quest]

Le 06/07/2016 à 16:24, François Lacombe a écrit :

Christian,

Ok avec ton point de vue, la relation complexifie pas mal le 
traitement des données.
Comment ça se passe quand un tronçon partage plusieurs ref ? cf 
autoroute avec les Axx nationaux et les Exx européens.



Pour ça on a :
- ref pour le Axx
- int_ref pour le Exx


Elles aident aussi pour la maintenance et la pérennité.
Le jour où la ref change, il faut être sur qu'elle soit modifiée 
partout où elle apparait. Si elle n'est posée que sur une relation, 
elle ne doit être modifiée qu'à un endroit unique.
Il y a, à peu près, 9 chances sur 10 que l'ancienne ref reste sur le 
petit segment que personne n'aura vu si on le répète sur tous les 
segments.




Mouais... pour le changement vu qu'on a de très fortes chances que la 
relation soit cassée quelque part, il sera toujours préférable de faire 
une requête overpass pour n'oublier aucun petit bout. Changer uniquement 
le ref sur la relation c'est un peu utopique malheureusement.


Relation ou pas, l'objet logique "départementale" peut être cassé dans 
tous les cas.
Par ailleurs, pour l'état de santé de la N4, on peut plutôt blâmer les 
contributeurs peu regardants que la relation en elle-même.




Oui, c'est pour ça que j'ai donné l'exemple... les relations se cassent 
très facilement et si on ne jardine pas en permanence se baser 
uniquement dessus n'est malheureusement pas fiable.


Question connexe : quelle différence vous faites entre une route 
départementale et une ligne de transport en commun ?
Moi aucune, pourtant la seconde est très rarement représentée 
autrement qu'avec une relation.




Un tronçon de route ne compte qu'un ref (pour les Exx c'est un tag 
séparé qui décrit autre chose) alors qu'un tronçon de rue peut voir 
passer plusieurs lignes de bus ou autres itinéraires en tout genre. 
C'est pour cela que les relations sont adaptées aux transports en commun.


On voit par ces multiples itinéraires combien les relations sont 
fragiles et complexe à maintenir... il suffit de voir le roman sur les 
panneaux M12 ;)
Imaginez la question "comment je fait pour indiquer que ce tronçon fait 
partie d'une départementale"...



La proposition ressemble pour l'instant beaucoup trop à la logique de 
"collection" et les arguments en faveur n'ont rien de nouveau 
(maintenabilité, élimination de redondance, etc) mais lors des 
discussions précédentes du même type, la conclusion avait été en 
défaveur des relations.
Le biais habituel est d'oublier (ou méconnaitre) qu'OSM est une base de 
données GEOGRAPHIQUES et pas une base de données relationnelle.


Attention à la relationite ;)


Et restons KISS <- à ne pas oublier !!!


PS: Cher TopographeFou... c'est ton premier sujet sur talk-fr... mais 
quel est ton "vécu" OSM ?


--
Christian Quest - OpenStreetMap France


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

Re: [Talk-es] Fuentes de Madrid

[Rafael Avila Coya]

Hola Santiago:

El Gestor de Tareas fue desarrollado por el HOT. En 5 años ya van más de 
2000 proyectos através de él [0]. Y, como digo, son ya varias las 
comunidades OSM que lo usan para proyectos de mapeo, mapatones, etc., de 
todo tipo [1][2][3][4].


Por ejemplo: usuarios de una comarca quieren mapear sistemáticamente 
todos los viales. Crean un proyecto en el Gestor de Tareas de OSM-es y 
se ponen a trabajar, y cada tarea es validada por el resto. Las 
posibilidades son infinitas. Además, para la importación en cuestión 
(las fuentes de Madrid) es la herramienta ideal.


Lo que hace falta es instalar un Gestor de Tareas en un servidor. No sé 
si OSM-es disponéis de un servidor para ello. Yo, de hecho, instalé uno, 
y no es complicado, pero prefiero que lo haga alguien con buena 
experiencia en instalación de servicios. El Gestor de Tareas usa 
postgres como base de datos y Apache como servidor. Las instrucciones 
están en su página de github [5].


Aunque su uso es bastante intuitivo, aquí tenéis una guía completa de 
uso [6].


Si queréis practicar para ver como funciona, podéis escoger por ejemplo 
una tarea del Gestor de Tareas del HOT. Un ejemplo sencillo para 
practicar: un proyecto de erradicación de la malaria en el Este de 
Swazilandia, en el que se pide que se cartografíen sólo chozas, casas y 
edificios, es decir, building=yes [7]. Pero hay montón de proyectos para 
elegir.


Pienso que disponer de un Gestor de Tareas propio ayudaría mucho a la 
comunidad OSM-es, no sólo para proyectos de importación de datos, sino 
para muchos otros.


Saludos,

Rafael.

[0] http://tasks.hotosm.org
[1] OSM EEUU: http://tasks.openstreetmap.us
[2] OSM Canadá: http://tasks.osmcanada.ca
[3] OSM India: http://tasks.openstreetmap.in
[4] OSM Colombia: http://tareas.openstreetmap.co
[5] https://github.com/hotosm/osm-tasking-manager2
[6] http://learnosm.org/es/coordination/tasking-manager
[7] http://tasks.hotosm.org/project/2005

On 05/07/16 19:28, Santiago Crespo wrote:

Hola Rafael,

1) Tampoco veo interesante añadir la dirección, ya que el Ayuntamiento
liberó también los datos de los números de portal y creo que los
acabaremos importando.

2) Tiene muy buena pinta este gestor de tareas. ¿Cómo empezamos a
usarlo? ¿Podemos usar algún servidor que ya esté o hay que montar uno?

Gracias,
Santiago Crespo

On 07/05/2016 02:28 PM, Rafael Avila Coya wrote:

Hola a todos/as:

Dejando de lado el tema de las proyecciones, un par de comentarios:

1) Etiquetado: deberíais considerar si es necesario añadir la dirección
a fuentes de agua. En caso de que sí penséis que es útil (yo no lo veo,
pero puedo estar equivocado), quizás deberíais considerar la posibilidad
de substituir add:street y add:housenumber por una sola etiqueta de
add:full. Os facilitaría el script, pero esto es sólo una idea.

2) De la wiki veo que seguís la idea de dividir el fichero en ficheros
con 50 fuentes cada uno, de forma similar a como se hizo con la
importación de farmacias.

Cuando lo organicé así fue porque no disponía de ninguna instancia del
Gestor de Tareas (Tasking Manager) [1] en la que crear un proyecto de
importación, de forma similar a como lo usamos en HOT. Ejemplos de estas
importaciones (nodos sólo) son:

* Importación de centros de salud en Borno, Nigeria [2]
* Importación de poblaciones de Liberia [3]
* Importación de centros educativos de Uganda [4]

La idea que propongo sería la de crear una instancia del Gestor de
Tareas para el proyecto OSM-es, como la que tienen ya muchas otras
comunidades OSM, como por ejemplo la comunidad OSM de Colombia [5].

Esto tendría múltiples ventajas:

a) No habría que hacer scripting para dividir fichero original en
múltiples ficheros. La división se hace automáticamente: cada usuario
escoge una cuadrícula del mapa, descarga los datos OSM en una capa de
JOSM y en una segunda capa los datos de fuentes para esa cuadrícula, con
solo hacer click en un enlace.

b) No hay necesidad de ninguna wiki de seguimiento, ni editar la wiki
cada vez que se completa una tarea, ni nada por el estilo. El usuario
completa una tarea y listo.

c) Permite una fácil validación, por otros usuarios, de las tareas
completadas.

d) Permite un fácil seguimiento del progreso de la importación.

e) Naturalmente, el Gestor de Tareas podría usarse para muchos otros
proyectos, no necesariamente de importación.

En suma, haría la vida del creador de proyectos de importación y de los
usuarios implicados mucho más fácil.

Todos esos proyectos de importación, y muchos otros, los he creado yo.
Si estáis interesados, os puedo guiar en el proceso.

Saludos,

Rafael.

[1] https://github.com/hotosm/osm-tasking-manager2
[2] http://tasks.hotosm.org/project/937
[3] http://tasks.hotosm.org/project/652
[4] http://tasks.hotosm.org/project/1434
[5] http://tareas.openstreetmap.co/

On 04/07/16 11:27, Alejandro Moreno Calvo wrote:

El ayuntamiento acaba de publicar la ubicación de todas las fuentes de
Madrid en

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[LeTopographeFou]

C'est en effet la méthode que j'utilise pour avoir un premier extract 
des RD d'un département afin de les vérifier, de les compléter et de les 
relier. Mais c'est laborieux et gourmand côté serveur.


C'est généralement quand on n'a pas besoin de quelque chose que l'on 
n'en voit pas l'intérêt. Là on touche à l’intérêt d'une relation de 
manière générale, et il y a déjà beaucoup d'infos sur le Wiki et sur 
Internet. Les relations sont assez récentes et les outils ne demandent 
qu'à évoluer. Plus une relation aura de sens, mieux elle sera exploitée 
par les outils. Pour ma part c'est justement le fait de centraliser 
certaines informations qui les rendra plus visibles et donc moins erronées.


Je fais notamment appel à vous pour m'aider à donner plus de sens (et de 
robustesse) à ce qui existe actuellement.


En ce qui me concerne (RD) voici les avantages que je vois :

1. Eviter de répéter 10 fois les mêmes propriétés avec le risque que si
   elles changent pour une way les autres ne soient pas mises à jour
   (et des infos obsolètes il y en a dans OSM nous le savons).
   Certaines RD ont une page wikipédia, elles ont toutes un symbol (on
   pourrait faire comme osmc et préciser dans la relation que c'est du
   noir sur fond jaune. Ex : )...
2. Structurer les infos pour améliorer les services tiers (Mapnik,
   Maps.ME, OsmAnd, WIkiSaria...). Là j'en appel à la créativité dont
   ils font preuve.
3. Améliorer la gestion des routes pouvant avoir plusieurs valeurs dans
   un même tag (notamment les routes Européennes qui, si je doute
   qu'elles prennent des RD, passent par des RN et autoroutes). Cela
   engendre des conflits de tags (ex : si on admet que l'on puisse
   avoir deux ref, comment associer chaque ref à un network ? à une url
   ? à un identifiant de base de donnée externe ?...). Là on a deux
   relations pour un segment de route, les données sont clairement
   organisées.
4. Tout simplement pouvoir rendre accessible une donnée au commun des
   mortels qui ne maîtrise pas les arcanes du système. Ce chantier est
   notamment venu du fait que je voulais voir le tracé de plusieurs RD
   en particulier et que le seul moyen était de passer 1h à composer
   une requête Overpass ! Là en un lien OSM permet de visualiser une RD
   avec toutes les informations associées. Wikipédia (ou autre) peut
   pointer dessus et vice-versa.

Alors oui bien sûr il y a un risque d'avoir des données cassées... c'est 
inévitable, avec ou sans relation j'en ai bien peur.


LeTopographeFou

Le 06/07/2016 16:13, Pierre-Yves Berrard a écrit :
Le 6 juillet 2016 à 15:27, Jérôme Amagat > a écrit :


Je comprends pas l'utilité de ces relations. si on veux toute la D
X du département Y, toute les info sont déjà dans les limites de
département et dans le ref des routes.
Des relations qui servent pas à grand chose c'est surtout des
relations qui seront vite cassées.

+1


___
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] import civici Emilia Romagna

[Gianmario Mengozzi]

Ocio che in alcune provincie / comuni l'import dei civici era già stato
fatto. In quei casi che si fa?

-- sent by  Nexus 5

Il 05 lug 2016 15:49, "Alessandro Palmas" 
ha scritto:

> Il 05/07/2016 15:29, Lorenzo "Beba" Beltrami ha scritto:
>
>>
>>
>> Se la suddivisione è quella mappata in questo articolo[1] non so se abbia
>> senso suddividere per provincie, sarebbe comunque disomogenea...
>> Potremmo creare delle macroaree o degli elenchi di comuni.
>> Oppure vedere se sono già suddivisi per zone sensate, come potrebbe
>> sembrare sempre dalla mappa nell'articolo[1].
>>
>>
> Puoi scegliere se per regione, provincia, singolo comune o alrti criteri.
> Io andrei per provincia, poi si può sempre suddividere ulteriormente.
>
> ___
> 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] Tag 'network' et 'name' pour une relation de type route départementale

[LeTopographeFou]

En effet.

Pour le moment j'ai pris le parti de faire des relations différentes et 
de ne pas tout mettre dans la même. C'est un choix arbitraire de ma 
part, qui peut être changé, motivé tout simplement par le fait que pour 
moi si ils sont référencés avec des suffixes de particularité, c'est 
qu'il doit y avoir un intérêt à les dissocier.


LeTopographeFou

Le 06/07/2016 12:27, Philippe Verdy a écrit :
L'ennui c'est que localement la référence change (on a des sections 
avec des lettres supplémentaires qui font pourtant partie de 
l'itinéraire de la départementale qui a la référence simplifiée. Cela 
survient notamment dans les sections à sens de circulation séparés, 
parfois même à plus d'1 kilomètre d'écart (dans un sens on traverse un 
village, par une rue à sens unique, dans l'autre on prend une bretelle 
de contournement... Ces deux sections sont lettrées différemment, 
aucune des deux n'a la référence simple de la départementale)


Le 6 juillet 2016 à 11:45, François Lacombe > a écrit :



Le 6 juillet 2016 à 11:33, JB > a écrit :

Pour ma part, je ne suis pas fan des relations non plus. Si
elles sont élégantes sur le plan de la modélisation, elles
sont peu accessibles aux nouveaux mappeurs. Attendez-vous à
avoir des doublons ref sur la relation + ref sur certains
tronçons.


Vu la quantité de données croissante, les nouveaux mappeurs vont
de plus en plus devoir s'adapter à une modélisation qui reste
stricte pour organiser toute cette connaissance.
On ne peut pas se passer des relations, mais on est pas obligé de
commencer par ce domaine quand on arrive sur osm.

Par contre sur la redondance ref sur le chemin et sur la relation,
je croyais que c'était nécessaire pour le rendu ? (i.e mapnik ne
sait pas aller chercher dans la relation pour dessiner le chemin
et ne sait pas rendre des relations sur la base de la géométrie de
ses membres).
A moins que ça ait changé ou que je me trompe complètement ?

François

___
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] Tag 'network' et 'name' pour une relation de type route départementale

[LeTopographeFou]

Sauf erreur de ma part OSM ne contient pas (encore) d'arbre des pays, 
régions, départements, cantons... ce ne sont pour le moment que des 
relations indépendantes, mises à plat, qui sont différenciées par leurs 
tags admin_level et cie. Et ce sont davantage des frontières que des 
départements, régions... En effet il me parait bizarre de mettre tout 
(routes, écoles...) "en vrac" dans les relations existantes, même avec 
les rôles qui vont bien.


La solution 1.5 est de toute la plus élégante mais aussi la plus 
ambitieuse par rapport à ce qui existe. Elle dépasse cette simple 
discussion sur les RD et nécessiterait une discussion plus globale. Vous 
m'emmenez sur un terrain que j'affectionne mais que je n'imaginais pas 
proposer à ce stade. Toutefois c'est en visant loin que l'on évite de 
piétiner. Elle présente l'avantage de ne plus nécessiter de champ 
network dans le cas présent (RD). En gros, on aurait :


 * Relation France
 o Une relation frontière avec pour rôle 'boundary' (relation actuelle)
 o Une capitale*
 o Un admin_level
 o Une relation par région avec pour rôle 'territory' (ou autre tag
   générique)
 + Une relation frontière avec pour rôle 'boundary' (relation
   actuelle)
 + Un chef lieu*
 + Un admin_level*
 + Une relation par département avec pour rôle 'territory' (ou
   autre tag générique)
 # Une relation frontière avec pour rôle 'boundary'
   (relation actuelle)
 # Un chef-lieu*
 # Un admin_level
 # Une relation par route départementale avec pour role
   'road' ou 'route' ou que sais-je. Pas besoin de lui
   mettre un network : le simple fait d'appartenir à un
   département suffit
 * Way 1 avec le tag ref qui va bien (pour
   compatibilité avec les outils actuels)
 * Way 2 avec le tag ref qui va bien (pour
   compatibilité avec les outils actuels)
 * ...
 # Une relation par ligne de bus départemental
 # Une relation par ville (à moins qu'il faille intercaler
   les cantons)
 * ... et ainsi de suite... vous avez saisi l'idée je pense
 o Une relation par route nationale avec pour role 'road' ou
   'route' ou que sais-je
 + Way 1 avec le tag ref qui va bien (pour compatibilité avec
   les outils actuels)
 + Way 2 avec le tag ref qui va bien (pour compatibilité avec
   les outils actuels)
 + ...
 o Une relation par autoroute avec pour role 'road' ou 'route' ou
   que sais-je
 + Way 1 avec le tag ref qui va bien (pour compatibilité avec
   les outils actuels)
 + Way 2 avec le tag ref qui va bien (pour compatibilité avec
   les outils actuels)
 + ...

* dans un premier temps en doublon de celui dans la boundary

Mais j'ai peur que ce soit trop pour mon déjà très ambitieux chantier. 
Et pour faire bien il faudrait que tous les pays utilisent la même archi 
sinon les outils galéreront. Donc c'est une discussion qui ne peut avoir 
lieu ici. Si les OSMiens initiés pense que c'est judicieux je peux faire 
une proposition dans ce sens sur le wiki en prenant la France pour 
terrain d'étude.


Les bonnes nouvelles : aux vues de ce qui se fait actuellement il n'y a 
pas de consensus et c'est quelque chose qui peut être déployé 
progressivement sans perte de compatibilité tout en conservant les 
network et autres is_in actuels. La France commencerai à se structurer 
d'une belle façon.


LeTopographeFou


Le 06/07/2016 11:40, François Lacombe a écrit :
+1 Avec Francescu sur le is_in : on a les relations pour ça, à minima 
l'analyse spatiale.


Également sur le fait de traduire une arborescence dans les tags, 
c'est pas forcément adapté.
Ici la route départementale est effectivement dans un périmètre fermé 
correspondant à la région, inutile de le faire transparaitre dans le code.
Ajouter ces infos dans les tags facilite la recherche c'est certain, 
mais ça pose autant de problèmes pour la maintenance (cf fusion des 
régions).
Parce qu'on pourrait faire pareil avec le millefeuille : canton, 
arrondissement... Et aussi on aurait du mal à traduire un cas où une 
route quelle qu'elle soit est partagée sur plusieurs territoires.


Si des codes ISO sont disponibles, autant les utiliser sans inventer 
autre chose
Et dans ces codes ISO si il y a le code pays, région ou autre, ca 
devient le problème de l'ISO et pas celui d'OSM.


Il y a un compromis à trouver entre grouper des objets selon une 
valeur de tag et utiliser une relation.
Ta proposition 1.5 est intéressante. Si je comprends bien, tu 
indiquerais network=* sur cette méta-relation ?
Résultat quand deux départements fusionnent : un seul objet à modifier 
et pas 300. L'édition de cet unique objet est cependant peu aisée vu 
le nombre de membres potentiel (question 

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[osm . sanspourriel]

Avec les anciennes nationales devenues départementales mais ayant le 
même numéro, on voit bien la limite de l'utilisation des relations ici.


Pour aller de Lorient à Quimperlé vous restez sur la D 765 (si vous ne 
prenez pas la N165).


La route change (une seule fois) de département et la route est la 
frontière du département.


Plus exactement le bas côté, mais pour la personne qui est sur la route, 
ce n'est pas identifiable... si ce n'est que le panneau d'entrée dans le 
Morbihan se trouve après le panneau d'un lieu dit ou il est précisé la 
commune de Guidel (qui est dans le Morbihan). Du coup il peut comprendre 
que la gestion de la route à ce niveau est faite par le département du 
Finistère et non par celui de Morbihan.


Les chemins de ref=D 765 sont bien dans les communes des départements 
respectifs.


On a beaucoup plus de chances d'avoir des données à jours avec les ref 
sur les chemins, les relations, surtout grandes restent trop fragiles.


Pas chaud non plus pour ces relations, la maintenance me semble plus 
hasardeuse que les gains (même si je vois ce que dit François).


Autant ça a un sens pour les lignes de bus (dont les noms sont 
indépendants de la voie et les références invisibles sur le terrain) 
autant sauf cas précis style Route Napoléon je doute de l'intérêt, 
Overpass semble plus indiqué.


Et oui, les noms sont à réserver aux vrais noms et les codes ISO à préférer.

L'exemple de la N 4 est intéressant : on voit que la N 4 dans les villes 
perd son statut, c'est une avenue, gérée par la commune, l'agglo ou la 
métropole. Ce n'est plus la N 4 ! L'itinéraire se retrouve par le 
gabarit de la route.


La route départementale est bien une chaussée, que Enedis profite pour 
faire passer un câble électrique le long de la départementale, c'est 
pour des raisons de facilité d'accès. Le jour où le département 
fusionnera avec le voisin, ça ne changera rien pour le statut du câble 
électrique qui restera propriété de l'autorité concédante.
Qui est souvent le syndicat d'énergie (par délégation de service de la 
commune) qui fusionnera (ou pas) en son heure.
Actuellement je vois des départementales gérées par DIR Ouest. Donc pas 
gérées au niveau départemental.


François, dans la ville, si la N 4 s'appelle Avenue Trucmuch et plus N 4 
ce n'est pas pour rien, il y a des endroits ou la N 4 s'appelle Route 
Nationale 4 dans FANTOIR (aux abréviations près).
Les itinéraires bis, convois exceptionnels, etc, je vois plus l'intérêt 
de les mettre sous forme de relation.
Quoi que pour les convois exceptionnels, c'est plutôt l'attribut hgv qui 
va être intéressant.


En résumé : si vous voulez les faire *et les maintenir*, pourquoi pas. 
Pour le moment les vrais itinéraires (voies vertes, lignes de bus) me 
semblent déjà mal maintenues car les éditeurs sont mal conçus pour les 
relations à nombreux éléments et à emprise géographique importante... 
comme les départementales.


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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[Stéphane Péneau]

Le 06/07/2016 à 18:09, François Lacombe a écrit :


> Une route départementale est un objet physique.
> Une ligne de transport ne l'est pas.
Dans un cas comme dans l'autre, la chaussée est l'objet physique.



Je vois ce que tu veux dire, mais je trouve que c'est un peu tiré par 
les cheveux.


La route départementale est une succession de tronçons de chaussée, la 
ligne de transport est une succession de tronçons de chaussée ou de 
chemin de fer
Et sur les mêmes tronçons de chaussée qu'empruntés par une route 
départementale on trouve également les itinéraires bis, les 
itinéraires pour les convois exceptionnels, etc
Pas de mon point de vue. Les tronçons sont la route départementale. Une 
RD n'est pas un itinéraire. Si un bout de RD est détruit (éboulement, 
etc..),  une déviation est mise en place, sans que les tronçons de 
celle-ci deviennent la RD.


Confondre l'usage et la nature nous posera des problèmes ensuite si on 
veut documenter avec plus de détails.
Dans le cas des RD, les 2 sont liés, on ne verra pas un chemin de terre 
se transformer en RD sans changer de largeur, de revêtement, etc.. Non ?


Stf

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

Re: [Talk-us] OSM-US Summer Mapathon

[Paul Johnson]

Not sure if Ill make it live, but I'll try to keep up with any replies to
notes I'm involved with quickly since I know I've got about a thousand out
there.

On Wed, Jul 6, 2016 at 2:18 PM, Russell Deffner 
wrote:

> Greetings everyone,
>
>
>
> Hopefully you’ve recovered from the long holiday weekend and are ready for
> some mapping! And forgive the short notice but this coming weekend is the
> quarterly mapathon. Several events are already listed on the wiki-page:
> http://wiki.openstreetmap.org/wiki/Mapathon/US_Summer_Mapathon_2016  - If
> you’re hosting an event, please add the details to that page.
>
>
>
> Happy Mapping!
>
> =Russ
>
>
>
> Russell Deffner
>
> russdeff...@gmail.com
>
> OSM-Colorado and Wyoming
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[François Lacombe]

Le 6 juillet 2016 à 20:03, Jérôme Amagat  a écrit :
>
>
> Ce que je voulais dire par cette ajout c’était pour différencié route dans
> le sens de la chaussée comme tu le dis et route, un itinéraire. Si tu te
> place n'importe où de la chaussée de la D31, tu peux dire que tu es sur la
> D31. par contre quelqu'un a pied sur l'itineraire du bus de la ligne L6 il
> ne dira jamais qu'il es sur la la L6.
>
Ça serait valable si en "ville" "les gens" savaient encore où passent les
départementales. Et vu qu'en "ville", "les gens" utilisent les noms de rue,
on ne doit pas mettre D xx mais le nom de la rue ?

Il pourrait aussi dire qu'il est sur l'itinéraire bis numéro 2, sur
l'itinéraire spécial 34 ou bien sur la route des convois exceptionnels.
Comment ça vous ne le dites pas vous ?

Enfin, chacun appelle sa route comme il le souhaite, c'est aussi un
avantage des relations : on se partage tous le même chemin, mais on ne
l’appelle pas de la même façon.
Où il est écrit que le bout de route doit comporter la référence de
l'itinéraire le plus connu qui passe dessus ? (et encore, le plus connu ça
reste à démontrer).



>
> D31 c'est pas un itinéraire c'est une route c'est du concret.
>
Pas pour tous en tout cas, certains centres d'exploitation n'utilisent pas
les numéros de départementale mais des numéros de section de chaussée.


> Une maison non plus n'est pas un objet physique, le mur en parpaing oui la
> charpente, la porte et c'est parce qu’on le décide que cette ensemble est
> une maison.
>

Tu vas te heurter au problème de l'échelle, est-ce réalisable de dessiner
la charpente sous josm ?
Dessiner plein de bout de route, y compris les obstacles, ronds point et
autre oui.


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

[Talk-us] OSM-US Summer Mapathon

[Russell Deffner]

Greetings everyone,

 

Hopefully you've recovered from the long holiday weekend and are ready for
some mapping! And forgive the short notice but this coming weekend is the
quarterly mapathon. Several events are already listed on the wiki-page:
http://wiki.openstreetmap.org/wiki/Mapathon/US_Summer_Mapathon_2016  - If
you're hosting an event, please add the details to that page.

 

Happy Mapping!

=Russ

 

Russell Deffner

russdeff...@gmail.com

OSM-Colorado and Wyoming

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

Re: [OSM-talk-be] Defecte drinkwaterfonteintjes

[Marc Gemis]

2016-07-06 20:17 GMT+02:00 Philippe Casteleyn :
> Punt van jaloezie = de programmeur en Google verdienen aan mijn
> vrijwilligerswerk.

en de OsmAnd developers, Mapbox, Telenav, etc. etc.
Maar als die app gratis is, hoe kan Google er dan aan verdienen.

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[Philippe Verdy]

La route départementale est toutr autant virtuelle qu'une ligne de
transport, avant tout c'est un poste comptable d'une collectivité, avec de
très nombreux objets physiques différents, tout un tas de contrats, de
règles communales, de travaux en cours à gérer ou à prévoir, et des tas
d'autres acteurs concernés, tout ce qu'on y trouve n'est d'ailleurs pas
géré par la collectivité départementale, il y a des tas de concessions
dessus aussi. Dans le détail (si on regarde la façon dont on les gère de
façon ultra-simplifiée dans OSM avec un simple chemin central), c'est uine
grosse approximation et ce n'est même pas l'objet physique réel. C'est
juste un itinéraire balisé. qui oublie la complexité réelle (voies, égouts,
panneaux routiers ou publicitaires, signalisation diverse, découpage
parcellaire multiple, plein de petites règles locales;on peut parler aussi
des trottoirs, fossés, égouts, murs ou clotures mitoyennes, voies d'accès
privées, et portails, interdictions de sationner devant, nature des
accotements).

Alors non, ces tracés de départementales ne sont pas du tout des objets
physique au même sens que les bâtiments.

On en reparlera le jour où on se mettra à représenter la surface des
routes, les lignes de séparation de voies réelles, les largeurs exactes des
voies trottoirs et accotements et la position exacte et le contenu réel de
chaque panneau, ou la moindre flèche directionnelle tracée sur le sol, ou
les zones hachurées, les bornes en plastique de séparation de voies, la
surface exacte des ralentisseurs et la topologie réelle des carrefours et
les cheminements dans les carrefours avec les points de franchisssements
réels...

Ceci dit cette approximation est généralement suffisante pour les
itinéraires routiers, mais on est encore très loin de l'objectif d'OSM de
produire une carte décimétrique. Pour les routes carossables la précision
est bien plus faible (à peine métrique souvent guère mieux que 5 mètres),
et c'est un problème pour l'usage pour autre chose que les véhicules
motorisés, notamment les cheminements piétons (et d'ailleurs les trottoirs
qu'on groupe souvent sur le même segment ne sont pas du ressort du
département, et souvent même c'est le cas pour les voies cyclables
latérales à l'initiative des communes ou assos/comités de quartiers ou des
aménageurs ou propriétaires limitrophes), et pour les réseaux connexes :
électricité, téléphonie/fibres, égouts, gaz, boites postales, places de
stationnement, arbres, plantations, etc. Les domaines publics se
superposent et on n'est pas encore entré dans les détails des réels
gestionnaires de chaque équipement.


Le 6 juillet 2016 à 18:02, Stéphane Péneau  a
écrit :

> Le 06/07/2016 à 16:24, François Lacombe a écrit :
>
>> Question connexe : quelle différence vous faites entre une route
>> départementale et une ligne de transport en commun ?
>> Moi aucune, pourtant la seconde est très rarement représentée autrement
>> qu'avec une relation.
>>
>
> Une route départementale est un objet physique.
> Une ligne de transport ne l'est pas.
>
> 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

[Talk-it] [OT] E' morto Kalman

[Francesco Pelullo]

Ciao a tutti,

Mi sembrava doveroso riportare la notizia:

http://www.tomshw.it/news/addio-a-emil-k-lm-n-il-matematico-padre-del-gps-78528

--
Ciao
/niubii/

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

Re: [Talk-it] Revert discutibile...

[Martin Koppenhoefer]

sent from a phone

> Il giorno 06 lug 2016, alle ore 18:43, Andrea Lattmann 
>  ha scritto:
> 
> Scusate ma è corretto fare un revert solo perché non si sa che landuse è?
> 
> http://www.openstreetmap.org/note/469053#map=12/44.8366/11.0546


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

[OSM-talk-be] Defecte drinkwaterfonteintjes

[Philippe Casteleyn]

Ik gebruik de tag stateofrepair=ok voor de drinkwaterfonteintjes waarvan ik dit 
jaar al vastgesteld heb dat ze water geven.Dat klopt natuurlijk niet, want er 
zijn perfect herstelde fonteintjes die geen water geven.
De app https://play.google.com/store/apps/details?id=de.bplaced.tapwater  geeft 
het allemaal mooi weer.  De stateofrepair kan ik daarop ook aanpassen en de 
kleur van de markers verandert dan.Rood = broken, groen = ok, blauw=te 
inspecteren.Punt van jaloezie = de programmeur en Google verdienen aan mijn 
vrijwilligerswerk.
Ik heb intussen Brussel binnen de vijfhoek geïnspecteerd.Nog te inspecteren 
:http://overpass-turbo.eu/s/hay


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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[Jérôme Amagat]

Le 6 juillet 2016 à 18:09, François Lacombe  a
écrit :

> Bonjour Alain,
>
> Le 6 juillet 2016 à 16:31, Alain VASSAULT <
> alain.vassa...@tranquillement.info> a écrit :
>
>> Désolé si je.dis une bêtise car je débute mais sur le wiki ils recommande
>> réf pour le Ax et réf_Nat pour le Exxx il me semble.
>>
>
> C'est ce qu'on trouve ici en effet
> http://wiki.openstreetmap.org/wiki/Key:ref#Examples_on_ways
> On fait donc porter à tous les tronçons plusieurs ref différentes.
>
> Le 6 juillet 2016 à 17:07, Jérôme Amagat  a
> écrit :
>
> > Pas d'accord : Pour ta D31 c'est la ref de la route (c'est bien ce que
> l'on tag dans osm avec highway) meme si il y a des chose annexe alors que
> pour ta L6 c'est la ref d'un trajet avec des arrêts voir des horaires.
> Pas d'accord non plus, c'est pas parce qu'on le tag dans OSM que ca
> correspond à la réalité :)
> Ce peut être commode, et encore ici je ne trouve pas parce que les
> modifications sont très mal gérées avec ce modèle.
>

Ce que je voulais dire par cette ajout c’était pour différencié route dans
le sens de la chaussée comme tu le dis et route, un itinéraire. Si tu te
place n'importe où de la chaussée de la D31, tu peux dire que tu es sur la
D31. par contre quelqu'un a pied sur l'itineraire du bus de la ligne L6 il
ne dira jamais qu'il es sur la la L6.

>
> D31 et L6 sont deux itinéraires qui empruntent des tronçons de route, les
> horaires sont attachés aux véhicules qui y circulent.
>
> D31 c'est pas un itineraire c'est une route c'est du concret.


> Le 6 juillet 2016 à 17:31, Pierre-Yves Berrard <
> pierre.yves.berr...@gmail.com> a écrit
> > Car aucun way ne porte le tag ref=L6.
> > Donc une requête comme celle montrée par Christian ((
> http://overpass-turbo.eu/s/hal) ne marchera pas.
> Là on est d'accord, et je suis également pour qu'aucun way ne porte ref=D
> 31
>
> > Note bien que je ne suis pas fondamentalement contre créer des relations
> pour une RD. Je voulais juste confirmer le fait que s'il s'agit juste une
> collection de highway, overpass ferait bien le job.
> Oui ça on est d'accord
>
> Le 6 juillet 2016 à 18:02, Stéphane Péneau  a
> écrit :
> > Une route départementale est un objet physique.
> > Une ligne de transport ne l'est pas.
> Dans un cas comme dans l'autre, la chaussée est l'objet physique.
>

Une maison non plus n'est pas un objet physique, le mur en parpaing oui la
charpente, la porte et c'est parce qu’on le décide que cette ensemble est
une maison.

>
> La route départementale est une succession de tronçons de chaussée, la
> ligne de transport est une succession de tronçons de chaussée ou de chemin
> de fer
> Et sur les mêmes tronçons de chaussée qu'empruntés par une route
> départementale on trouve également les itinéraires bis, les itinéraires
> pour les convois exceptionnels, etc
>
> Parce que si la ligne de transport passe en site propre, on ne dit pas
> pour autant que la ligne de transport est un objet physique.
> Confondre l'usage et la nature nous posera des problèmes ensuite si on
> veut documenter avec plus de détails.
>
> François
>
>
>
> ___
> 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] Script per creare mappe obf (OsmAnd) senza problemi di OutOfMemory

[Stefano Droghetti]

Il 06/07/2016 18:37, Andrea Lattmann ha scritto:

Sarebbe bello realizzare l' interfaccia in kivy... E si lo so, ho sparato 
troppo in alto! :-D

Prima volta che lo sento :-)
Purtroppo le mie conoscenze di programmazione sono poche e tutte rivolte 
solo a sistemi Linux :-( In realtà un po' di python lo conosco, quindi 
se avessi tempo lo farei io il porting, ma sinceramente mi sembra tempo 
sprecato, non mi soffermerei troppo su elaborate interfacce e 
programmini user friendly, per questi motivi:
- lo script si basa comunque su un programma di terzi, che è 
OsmAndCreator, nonché su splitter.
- fra un po' di tempo OsmAnd passerà a mappe incrementali, così si 
eliminerà il problema dei file più lunghi di 4GB e dell'outofmemory. 
Quindi il mio script serve solo momentaneamente.
- gli script bash da poco o fra poco che io sappia dovrebbero funzionare 
anche su Windows, no? Tutta quella cosa che Canonical aveva portato "il 
terminale di Linux" su Windows non serve a questo?
- lo script è molto semplice e credo quindi che esistano comandi dos per 
farne un porting su Windows comunque senza problemi, un file bat cioè.


--
Stefano Droghetti
www.stefanodroghetti.it
stefano.droghe...@gmail.com


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

Re: [Talk-it] Ubuntu Touch e OpenStreetMap

[Martin Koppenhoefer]

sent from a phone

> Il giorno 06 lug 2016, alle ore 19:24, Aury88  ha 
> scritto:
> 
> mapbox tra le altre cose vende tilenon penso sia disposta a fare una
> cosa del genere che potenzialmente potrebbe inimicargli gli altri n-clienti
> che pagano per avere lo stesso servizio


se parliamo di un progetto open e non-profit forse si, altrimenti no. Sarebbe 
anche una pubblicità per loro.

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

Re: [Talk-it] Ubuntu Touch e OpenStreetMap

[Aury88]

dieterdreist wrote
> potrebbe chiedere a qualcuno come Mapbox se volessero sponsorizzare il suo
> progetto, oppure trovare degli sponsor per pagare qualcuno che gli
> fornisca i tiles o finanzia un server ed il traffico per generare e
> distribuire i propri tiles.

 mapbox tra le altre cose vende tilenon penso sia disposta a fare una
cosa del genere che potenzialmente potrebbe inimicargli gli altri n-clienti
che pagano per avere lo stesso servizio.
la questione degli sponsor ci sono state due proposte: introduzione della
pubblicità e finanziamento tramite donazioni; la prima è stata scartata
istantaneamente la seconda per le tariffe richieste dai vari servizi che
forniscono tile non è possibile raccogliere abbastanza soldi con abbastanza
regolarità da rendere affidabile il servizio...l'attuale smartphone UT non
ha semplicemente diffusione sufficiente per permettere la raccolta di denaro
tramite donazione in quantità sufficiente (si sta provvedendo a rendere
l'app convergente su più tipi di dispositivo ma cambia poco...è una app per
smartphone principalmente).l'altra soluzione sarebbe rendere l'app a
pagamento ma lo sviluppatore non vuole.
stesso discorso per il server in proprio e la banda...per quanto il server
sarebbe un costo una tantum (quasi) la banda e l'elettricità necessita di un
introito al momento non supportabile in maniera affidabile dagli utenti
dell'app.
ho proposto di contattare canonical per mettere in piedi un server (sanno
come si fa) che fornisca tile agli applicativi su ubuntu ma ha sempre
glissato su questa  proposta







-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/Ubuntu-Touch-e-OpenStreetMap-tp5834454p5877474.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-es] Fuentes de Madrid

[Santiago Crespo]

Perdonad la confusión, creo que está bien situada la fuente del parque
del bronce.

Aquí podéis ver como queda, usando los 2 sistemas de coordenadas
dependiendo de la localización (si están en "PARQUE HISTORICO"...25830
y el resto 23030), comparado con las fuentes que ya hay en OSM:

https://umap.openstreetmap.fr/en/map/untitled-map_93422

Saludos,
Santiago Crespo

On 07/05/2016 07:14 PM, Santiago Crespo wrote:
> No estoy 100% seguro pero creo que ya lo tengo.
> 
> Las fuentes con la etiqueta "PARQUE HISTORICO SINGULAR O FORESTAL" (ej:
> el Retiro) están en 25830 y el resto en 23030. La única excepción que he
> visto por ahora es la fuente del parque del bronce, que estando en una
> zona verde normal usa 25830.
> 
> Saludos,
> Santiago Crespo
> 
> 
> On 07/05/2016 02:48 PM, Emilio Gómez Fernández wrote:
>> Es extraño. En algunas zonas se ajusta más con 23030 y en otras con
>> 25830, como si los datos del CSV proviniesen de fuentes con diferentes
>> sistemas de coordenadas, no se... un cacao.
>>
>> http://u.osmfr.org/m/93231/
>>
>> Un saludo.
>>
>> Emilio Gómez
>>
>>
>> El 5 de julio de 2016, 12:00, Luis García Castro > > escribió:
>>
>>
>> El 5 de julio de 2016, 11:53, Emilio Gómez Fernández
>> >
>> escribió:
>>
>> Efectivamente parece que en la zona del Retiro no se ajusta nada
>> bien a lo que ya hay en OSM [1], pero en otras partes veo que si
>> que existe una correlación.[2]
>>
>>
>> Yo sí veo que se ajusta bastante en las dos imágenes que ha puesto
>> Jorge (con alguna diferencia lógica y esperable)... no me cuadran
>> los puntos de su imagen con tu primera superposición :-/
>>
>>
>> -- 
>>
>> Luis Garcí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
>>
> 
> ___
> 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-it] Ubuntu Touch e OpenStreetMap

[Aury88]

Luigi Toscano wrote
> Capisco che si tratta di una soluzione più complessa, ma se invece di
> usare i
> tile precotti puntasse su mappe vettoriali renderizzate al volo, non
> potrebbe
> riciclare i(l formato dei) file di OsmAnd?
> O magari lo fa già/è nei piani.

il renderizzati al volo intendi lato client? gliel'ho proposto ma nonostante
i miei tentativi di convincerlo non  gli piace la velocità della generazione
del rendering nel client dai dati vettoriali. 
comunque penso conosca bene osmand e quindi il suo formato, perciò sarà di
sicuro una opzione che valuterà se e quando deciderà di passare al
vettoriale.




-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/Ubuntu-Touch-e-OpenStreetMap-tp5834454p5877471.html
Sent from the Italy General mailing list archive at Nabble.com.

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

[Talk-it] Revert discutibile...

[Andrea Lattmann]

Scusate ma è corretto fare un revert solo perché non si sa che landuse è?

http://www.openstreetmap.org/note/469053#map=12/44.8366/11.0546

Andrea Lattmann

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

Re: [Talk-it] Script per creare mappe obf (OsmAnd) senza problemi di OutOfMemory

[Andrea Lattmann]

Sarebbe bello realizzare l' interfaccia in kivy... E si lo so, ho sparato 
troppo in alto! :-D

Andrea Lattmann

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[François Lacombe]

Bonjour Alain,

Le 6 juillet 2016 à 16:31, Alain VASSAULT <
alain.vassa...@tranquillement.info> a écrit :

> Désolé si je.dis une bêtise car je débute mais sur le wiki ils recommande
> réf pour le Ax et réf_Nat pour le Exxx il me semble.
>

C'est ce qu'on trouve ici en effet
http://wiki.openstreetmap.org/wiki/Key:ref#Examples_on_ways
On fait donc porter à tous les tronçons plusieurs ref différentes.

Le 6 juillet 2016 à 17:07, Jérôme Amagat  a écrit :

> Pas d'accord : Pour ta D31 c'est la ref de la route (c'est bien ce que
l'on tag dans osm avec highway) meme si il y a des chose annexe alors que
pour ta L6 c'est la ref d'un trajet avec des arrêts voir des horaires.
Pas d'accord non plus, c'est pas parce qu'on le tag dans OSM que ca
correspond à la réalité :)
Ce peut être commode, et encore ici je ne trouve pas parce que les
modifications sont très mal gérées avec ce modèle.

D31 et L6 sont deux itinéraires qui empruntent des tronçons de route, les
horaires sont attachés aux véhicules qui y circulent.

Le 6 juillet 2016 à 17:31, Pierre-Yves Berrard <
pierre.yves.berr...@gmail.com> a écrit
> Car aucun way ne porte le tag ref=L6.
> Donc une requête comme celle montrée par Christian ((
http://overpass-turbo.eu/s/hal) ne marchera pas.
Là on est d'accord, et je suis également pour qu'aucun way ne porte ref=D 31

> Note bien que je ne suis pas fondamentalement contre créer des relations
pour une RD. Je voulais juste confirmer le fait que s'il s'agit juste une
collection de highway, overpass ferait bien le job.
Oui ça on est d'accord

Le 6 juillet 2016 à 18:02, Stéphane Péneau  a
écrit :
> Une route départementale est un objet physique.
> Une ligne de transport ne l'est pas.
Dans un cas comme dans l'autre, la chaussée est l'objet physique.

La route départementale est une succession de tronçons de chaussée, la
ligne de transport est une succession de tronçons de chaussée ou de chemin
de fer
Et sur les mêmes tronçons de chaussée qu'empruntés par une route
départementale on trouve également les itinéraires bis, les itinéraires
pour les convois exceptionnels, etc

Parce que si la ligne de transport passe en site propre, on ne dit pas pour
autant que la ligne de transport est un objet physique.
Confondre l'usage et la nature nous posera des problèmes ensuite si on veut
documenter avec plus de détails.

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[Stéphane Péneau]

Le 06/07/2016 à 16:24, François Lacombe a écrit :
Question connexe : quelle différence vous faites entre une route 
départementale et une ligne de transport en commun ?
Moi aucune, pourtant la seconde est très rarement représentée 
autrement qu'avec une relation.


Une route départementale est un objet physique.
Une ligne de transport ne l'est pas.

Stf

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[Pierre-Yves Berrard]

Le 6 juillet 2016 à 16:52, François Lacombe  a
écrit :

> Bonjour Pierre-Yves,
>
> Le 6 juillet 2016 à 16:39, Pierre-Yves Berrard <
> pierre.yves.berr...@gmail.com> a écrit :
>
>> Deux différences notables :
>> On peut retrouver tous les éléments d'une route départementale par leur
>> ref, pas pour une ligne de transport.
>>
>

> Peux-tu m'expliquer pourquoi ?
>
> Que ce soit la D31 ou la L6 ca reste une ref, non ?
>

Car aucun way ne porte le tag ref=L6.
Donc une requête comme celle montrée par Christian ((
http://overpass-turbo.eu/s/hal) ne marchera pas.

Note bien que je ne suis pas fondamentalement contre créer des relations
pour une RD. Je voulais juste confirmer le fait que s'il s'agit juste une
collection de highway, overpass ferait bien le job.

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[Jérôme Amagat]

Le 6 juillet 2016 à 16:52, François Lacombe  a
écrit :

> Bonjour Pierre-Yves,
>
> Le 6 juillet 2016 à 16:39, Pierre-Yves Berrard <
> pierre.yves.berr...@gmail.com> a écrit :
>
> Deux différences notables :
>> On peut retrouver tous les éléments d'une route départementale par leur
>> ref, pas pour une ligne de transport.
>>
> Peux-tu m'expliquer pourquoi ?
>
> Que ce soit la D31 ou la L6 ca reste une ref, non ?
> On peut retrouver la D31 dans plusieurs départements, la L6 sur plusieurs
> réseaux de transport en commun.
>
> La ligne de transport, comporte d'autres éléments, comme la position des
>> arrêts.
>>
> La route départementale a des tronçons de route, mais aussi des bornes,
> des panneaux, des boucles de comptages...
> 
>
Pas d'accord : Pour ta D31 c'est la ref de la route (c'est bien ce que l'on
tag dans osm avec highway) meme si il y a des chose annexe alors que pour
ta L6 c'est la ref d'un trajet avec des arrêts voir des horaires.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[Alain VASSAULT]

" Comment ça se passe quand un tronçon partage plusieurs ref ? cf autoroute 
avec les Axx nationaux et les Exx européens."

Hello, 
Désolé si je.dis une bêtise car je débute mais sur le wiki ils recommande réf 
pour le Ax et réf_Nat pour le Exxx il me semble. 

Tranquille 

Le 6 juillet 2016 16:24:25 CEST, "François Lacombe"  
a écrit :
>Christian,
>
>Ok avec ton point de vue, la relation complexifie pas mal le traitement
>des
>données.
>Comment ça se passe quand un tronçon partage plusieurs ref ? cf
>autoroute
>avec les Axx nationaux et les Exx européens.
>
>Elles aident aussi pour la maintenance et la pérennité.
>Le jour où la ref change, il faut être sur qu'elle soit modifiée
>partout où
>elle apparait. Si elle n'est posée que sur une relation, elle ne doit
>être
>modifiée qu'à un endroit unique.
>Il y a, à peu près, 9 chances sur 10 que l'ancienne ref reste sur le
>petit
>segment que personne n'aura vu si on le répète sur tous les segments.
>
>Relation ou pas, l'objet logique "départementale" peut être cassé dans
>tous
>les cas.
>Par ailleurs, pour l'état de santé de la N4, on peut plutôt blâmer les
>contributeurs peu regardants que la relation en elle-même.
>
>Question connexe : quelle différence vous faites entre une route
>départementale et une ligne de transport en commun ?
>Moi aucune, pourtant la seconde est très rarement représentée autrement
>qu'avec une relation.
>
>
>A+
>
>
>*François Lacombe*
>
>fl dot infosreseaux At gmail dot com
>www.infos-reseaux.com
>@InfosReseaux 
>
>Le 6 juillet 2016 à 15:31, Christian Quest  a
>écrit :
>
>> Le 06/07/2016 à 11:33, JB a écrit :
>>
>>> Bonjour,
>>> Personnellement, je ne suis pas convaincu par le name=*. Pour moi,
>le ref
>>> suffit largement, ce que tu mets dans name est juste une description
>de ce
>>> ref.
>>> Pour ma part, je ne suis pas fan des relations non plus. Si elles
>sont
>>> élégantes sur le plan de la modélisation, elles sont peu accessibles
>aux
>>> nouveaux mappeurs. Attendez-vous à avoir des doublons ref sur la
>relation +
>>> ref sur certains tronçons.
>>> JB.
>>>
>>>
>> Et j'espère bien qu'on en aura des doublons de ref car si l'objectif
>en
>> créant ces relations est de supprimer les tags communs, pourquoi
>s'arrêter
>> au ref=*, pourquoi ne pas virer aussi les highway=*... (je pousse à
>> l'extrême pour montrer le problème).
>>
>> L'immense majorité des outils qui utilisent les données OSM ne
>sauraient
>> plus faire un rendu correct voire un calcul d'itinéraire.
>>
>> Ces relations ne me semble pas une super idée, on est pas loin de la
>> notion de collections.
>>
>> Si l'on veut obtenir l'ensemble des tronçons composant la
>départementale 1
>> dans le Val de Marne et bien une requête overpass le fait sans
>problème (
>> http://overpass-turbo.eu/s/hal), pas besoin de relation qui sera très
>> souvent cassée pour cela.
>>
>> Je m'étais amusé à créer une relation pour quelques route nationales
>(pour
>> garder trace de ces routes mythiques qui passent en
>départementales)... à
>> quoi ressemble-t-elle après plusieurs années d'existence ?
>>
>> Exemple avec la N4: http://www.openstreetmap.org/relation/2307408
>>
>> Et une liste des network=FR:N-road http://overpass-turbo.eu/s/ham
>>
>>
>> Pour le name, il ne doit pas servir à décrire et ne devrait pas être
>> penser pour être parsé, c'est le rôle des tags de fournir une
>description
>> sémantique non ambigue, name sert à nommer ce qui porte un nom
>(exemple
>> avec la Route Napoléon).
>>
>>
>> Bref, pas chaud pour ces relations...
>>
>> Pour info, il y a une analyse osmose qui aide à trouver les
>différences
>> entre OSM et Route500... et donc les manques potentiels dans OSM
>(attention
>> Route500 peut aussi se tromper ou ne pas être à jour).
>>
>> --
>> 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

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[François Lacombe]

Bonjour Pierre-Yves,

Le 6 juillet 2016 à 16:39, Pierre-Yves Berrard <
pierre.yves.berr...@gmail.com> a écrit :

> Deux différences notables :
> On peut retrouver tous les éléments d'une route départementale par leur
> ref, pas pour une ligne de transport.
>
Peux-tu m'expliquer pourquoi ?

Que ce soit la D31 ou la L6 ca reste une ref, non ?
On peut retrouver la D31 dans plusieurs départements, la L6 sur plusieurs
réseaux de transport en commun.

La ligne de transport, comporte d'autres éléments, comme la position des
> arrêts.
>
La route départementale a des tronçons de route, mais aussi des bornes, des
panneaux, des boucles de comptages...



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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[François Lacombe]

Christian,

Ok avec ton point de vue, la relation complexifie pas mal le traitement des
données.
Comment ça se passe quand un tronçon partage plusieurs ref ? cf autoroute
avec les Axx nationaux et les Exx européens.

Elles aident aussi pour la maintenance et la pérennité.
Le jour où la ref change, il faut être sur qu'elle soit modifiée partout où
elle apparait. Si elle n'est posée que sur une relation, elle ne doit être
modifiée qu'à un endroit unique.
Il y a, à peu près, 9 chances sur 10 que l'ancienne ref reste sur le petit
segment que personne n'aura vu si on le répète sur tous les segments.

Relation ou pas, l'objet logique "départementale" peut être cassé dans tous
les cas.
Par ailleurs, pour l'état de santé de la N4, on peut plutôt blâmer les
contributeurs peu regardants que la relation en elle-même.

Question connexe : quelle différence vous faites entre une route
départementale et une ligne de transport en commun ?
Moi aucune, pourtant la seconde est très rarement représentée autrement
qu'avec une relation.


A+


*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

Le 6 juillet 2016 à 15:31, Christian Quest  a
écrit :

> Le 06/07/2016 à 11:33, JB a écrit :
>
>> Bonjour,
>> Personnellement, je ne suis pas convaincu par le name=*. Pour moi, le ref
>> suffit largement, ce que tu mets dans name est juste une description de ce
>> ref.
>> Pour ma part, je ne suis pas fan des relations non plus. Si elles sont
>> élégantes sur le plan de la modélisation, elles sont peu accessibles aux
>> nouveaux mappeurs. Attendez-vous à avoir des doublons ref sur la relation +
>> ref sur certains tronçons.
>> JB.
>>
>>
> Et j'espère bien qu'on en aura des doublons de ref car si l'objectif en
> créant ces relations est de supprimer les tags communs, pourquoi s'arrêter
> au ref=*, pourquoi ne pas virer aussi les highway=*... (je pousse à
> l'extrême pour montrer le problème).
>
> L'immense majorité des outils qui utilisent les données OSM ne sauraient
> plus faire un rendu correct voire un calcul d'itinéraire.
>
> Ces relations ne me semble pas une super idée, on est pas loin de la
> notion de collections.
>
> Si l'on veut obtenir l'ensemble des tronçons composant la départementale 1
> dans le Val de Marne et bien une requête overpass le fait sans problème (
> http://overpass-turbo.eu/s/hal), pas besoin de relation qui sera très
> souvent cassée pour cela.
>
> Je m'étais amusé à créer une relation pour quelques route nationales (pour
> garder trace de ces routes mythiques qui passent en départementales)... à
> quoi ressemble-t-elle après plusieurs années d'existence ?
>
> Exemple avec la N4: http://www.openstreetmap.org/relation/2307408
>
> Et une liste des network=FR:N-road http://overpass-turbo.eu/s/ham
>
>
> Pour le name, il ne doit pas servir à décrire et ne devrait pas être
> penser pour être parsé, c'est le rôle des tags de fournir une description
> sémantique non ambigue, name sert à nommer ce qui porte un nom (exemple
> avec la Route Napoléon).
>
>
> Bref, pas chaud pour ces relations...
>
> Pour info, il y a une analyse osmose qui aide à trouver les différences
> entre OSM et Route500... et donc les manques potentiels dans OSM (attention
> Route500 peut aussi se tromper ou ne pas être à jour).
>
> --
> 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-latam] Como se puede editar una vivienda de mas de tres pisos

[hyan...@gmail.com]

2016-07-06 9:07 GMT-05:00 joost schouppe :

> Creo que la propuesta de Marco Antonio es la mas practica. Esta
> documentada en la wiki aqui:
>
> http://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging#Simple_POI_mapping
>
>
OK, bajo ese modelo de datos, como podríamos indicar en una edificación
simple de tres pisos, los usos que tiene por cada nivel? Sería algo como
agregar los tres nodos de los amenities e indicar el nivel o cuarto en el
que se encentran? Es decir, es un objeto relacionado y dentro de la
edificación?  Sería efectivo para una referencia catastral de la
edificación?
___
talk-latam mailing list
talk-latam@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-latam

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[Pierre-Yves Berrard]

Le 6 juillet 2016 à 15:27, Jérôme Amagat  a écrit :

> Je comprends pas l'utilité de ces relations. si on veux toute la D X du
> département Y, toute les info sont déjà dans les limites de département et
> dans le ref des routes.
> Des relations qui servent pas à grand chose c'est surtout des relations
> qui seront vite cassées.
>

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[Jérôme Amagat]

>
> Pour info, il y a une analyse osmose qui aide à trouver les différences
> entre OSM et Route500... et donc les manques potentiels dans OSM (attention
> Route500 peut aussi se tromper ou ne pas être à jour).
>

Soit je la trouve plus cette analyse soit c'est celle là :
http://osmose.openstreetmap.fr/fr/errors/?source=14708=7170=2 et
il y a 0 erreur.
C'est moi qui sais pas chercher ou l'analyse bug.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-latam] Como se puede editar una vivienda de mas de tres pisos

[Marco Antonio]

On Wed, 6 Jul 2016 09:54:38 -0400 Marco Antonio
 wrote:

> On Wed, 06 Jul 2016 13:27:45 + carlos felipe castillo
>  wrote:
> 
> > Una pregunta técnica, si tengo una edificación de 3 pisos y en el
> > 1er piso hay un restaurante, en el 2do piso un billar y en el 3er
> > piso una discoteca... ¿Cómo se debe tiquetar?
> 
> Carlos, en el edificio building:levels=3 y en pois usá level=0 planta
> baja, level=1 billard, level=2 el otro.

Me olvidé mencionar que pueden usar http://openlevelup.net/ para ir
probando si lo hicieron bien y refleja la realidad. Más info de mejores
prácticas de etiquetado aquí ->

https://wiki.openstreetmap.org/wiki/OpenLevelUp

abrazos,

Marco Antonio
@51114u9

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

Re: [talk-latam] Como se puede editar una vivienda de mas de tres pisos

[hyan...@gmail.com]

El 6 de julio de 2016, 8:27, carlos felipe castillo 
escribió:

> Buenos días comunidad,
>
> Una pregunta técnica, si tengo una edificación de 3 pisos y en el 1er piso
> hay un restaurante, en el 2do piso un billar y en el 3er piso una
> discoteca... ¿Cómo se debe tiquetar?
>
> Gracias.
>
>
Hola Carlos,

interesante y pertinente pregunta (para el uso catastral), para mapear los
pisos o niveles de una edificación, así como su altura se usa las etiquetas
tipo 'levels':

http://wiki.openstreetmap.org/wiki/Key:building:levels

Para identificar que actividad o 'amenity' funcionan me parece que es
necesario construir y documentar en la wiki nuevas etiquetas, algunas ideas:

building:levels:1=restaurant
bulding:levels:1:amenity=restaurant

¿les parece bien?

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

Re: [talk-latam] Como se puede editar una vivienda de mas de tres pisos

[Marco Antonio]

On Wed, 06 Jul 2016 13:27:45 + carlos felipe castillo
 wrote:

> Una pregunta técnica, si tengo una edificación de 3 pisos y en el 1er
> piso hay un restaurante, en el 2do piso un billar y en el 3er piso una
> discoteca... ¿Cómo se debe tiquetar?

Carlos, en el edificio building:levels=3 y en pois usá level=0 planta
baja, level=1 billard, level=2 el otro.

abrazos,

Marco Antonio
@51114u9

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[Christian Quest]

Le 06/07/2016 à 11:33, JB a écrit :

Bonjour,
Personnellement, je ne suis pas convaincu par le name=*. Pour moi, le 
ref suffit largement, ce que tu mets dans name est juste une 
description de ce ref.
Pour ma part, je ne suis pas fan des relations non plus. Si elles sont 
élégantes sur le plan de la modélisation, elles sont peu accessibles 
aux nouveaux mappeurs. Attendez-vous à avoir des doublons ref sur la 
relation + ref sur certains tronçons.

JB.



Et j'espère bien qu'on en aura des doublons de ref car si l'objectif en 
créant ces relations est de supprimer les tags communs, pourquoi 
s'arrêter au ref=*, pourquoi ne pas virer aussi les highway=*... (je 
pousse à l'extrême pour montrer le problème).


L'immense majorité des outils qui utilisent les données OSM ne sauraient 
plus faire un rendu correct voire un calcul d'itinéraire.


Ces relations ne me semble pas une super idée, on est pas loin de la 
notion de collections.


Si l'on veut obtenir l'ensemble des tronçons composant la départementale 
1 dans le Val de Marne et bien une requête overpass le fait sans 
problème (http://overpass-turbo.eu/s/hal), pas besoin de relation qui 
sera très souvent cassée pour cela.


Je m'étais amusé à créer une relation pour quelques route nationales 
(pour garder trace de ces routes mythiques qui passent en 
départementales)... à quoi ressemble-t-elle après plusieurs années 
d'existence ?


Exemple avec la N4: http://www.openstreetmap.org/relation/2307408

Et une liste des network=FR:N-road http://overpass-turbo.eu/s/ham


Pour le name, il ne doit pas servir à décrire et ne devrait pas être 
penser pour être parsé, c'est le rôle des tags de fournir une 
description sémantique non ambigue, name sert à nommer ce qui porte un 
nom (exemple avec la Route Napoléon).



Bref, pas chaud pour ces relations...

Pour info, il y a une analyse osmose qui aide à trouver les différences 
entre OSM et Route500... et donc les manques potentiels dans OSM 
(attention Route500 peut aussi se tromper ou ne pas être à jour).


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[Jérôme Amagat]

Je comprends pas l'utilité de ces relations. si on veux toute la D X du
département Y, toute les info sont déjà dans les limites de département et
dans le ref des routes.
Des relations qui servent pas à grand chose c'est surtout des relations qui
seront vite cassées.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Script per creare mappe obf (OsmAnd) senza problemi di OutOfMemory

[Max1234Ita]

Il codice sembra abbastanza lineare, non escludo che sia facilmente portabile
in Python (che è anche in grado di eseguire il download di file dal web
senza ricorrere ad utility esterne).

Il problema, quindi, al momento è QUANDO riuscirò ad applicarmici! XD
Per ora prendo nota e mi tengo da parte il necessario, appena avrò maniera
ci provo!

Ciao e grazie,
Max



--
View this message in context: 
http://gis.19327.n5.nabble.com/Script-per-creare-mappe-obf-OsmAnd-senza-problemi-di-OutOfMemory-tp5877254p5877445.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] Script per creare mappe obf (OsmAnd) senza problemi di OutOfMemory

[Stefano Droghetti]

La nuova versione di Osmux, con tutte le istruzioni, la trovate qui:
http://www.stefanodroghetti.it/mappe-gratis-per-navigatori#fabbric

Qualche buon'anima mi farebbe sapere se funziona? Se c'è qualcosa da 
cambiare?


--
Stefano Droghetti
www.stefanodroghetti.it
stefano.droghe...@gmail.com


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

Re: [OSM-Talk-ZA] Fwd: WiFi Hotspots in SA

[Dawid Loubser]

Hi Michael,

Nice idea! Some thoughts:

  * There are some existing open projects that specifically collect and
share data of e.g. cellphone towers, wifi networks etc (in at
attempt to offer an open alternative to Google location services,
which keep wifi networks data locations private).
  * Check out: Mozilla Location Services
, Open WLAN Map
 (their map
 seems to have some data for South
Africa already) etc.
  * Are your thoughts similar to what Wigle  is doing?

OpenStreetMap's mandate is to contain information about
physically-visible things, so it's unlikely that wifi networks will
every be incorporated into the dataset. I'm guessing you want to augment
your own geo-located data with OSM as map backdrop?

You should probably figure out how your app's interaction will be with
OSM? One option is to do what, for example, OSMAND is doing - use the
raw data dumps to render your own vector maps in your app. This is
non-trivial, but enables an app to work without an internet connection.

A simpler option is to use rendered OSM tiles as the "backdrop" to your
own wifi map and app. At some point, the official OSM tile rendering
servers might see this abuse (not sure.. Grant Slater should chip in
here...) but it's not very difficult to set up your own "mirror"
tile-rendering server - with the advantage that you also can control the
styling and features included in the rendered map.

If you are using web technologies to build your app, there are a ton of
libraries (like leaflet ) to render an
interactive slippy map, adding your own layers.

If you're writing a native app (e.g. Java, Android) there are similar
libraries, but I have no experience with them.

good luck!

Dawid Loubser


On 06/07/2016 11:38, Michael Graaf wrote:
>
>
> -- Forwarded message --
> From: *Michael Graaf*  >
> Date: Wednesday, July 6, 2016
> Subject: WiFi Hotspots in SA
> To: "impo...@openstreetmap.org "
> >,
> talk...@openstreetmaps.org 
>
>
> Greetings all,
>
> I write on behalf of a team preparing to create an app (free as in
> beer as well as in speech) which will help users find WiFi hotspots
> and also review them or report new ones. We already have some
> data-sets which appear to be public-domain, but these things keep
> changing hence our intention to have real-time crowdsourcing. 
>
> Initially we thought of using both Google Maps and OSM but on closer
> investigation, discovered that above a minimal level of use, Google
> API costs some dollars, so we discarded that idea.
>
> None of us has done this kind of thing before so we are hoping for
> guidance and assistance. I found your addresses in the OSM Import
> Guidelines page.
>
> yours in anticipation,
>
> Michael Graaf.
>
>
>
> ___
> Talk-ZA mailing list
> Talk-ZA@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-za

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

Re: [Talk-it] Ubuntu Touch e OpenStreetMap

[Luigi Toscano]

Aury88 ha scritto:
> Marcos sta provando a mettere in piedi un sistema di mappe offline e
> realizzare un proprio tile server, ma ha risorse limitate e il suo computer
> home server (un vecchio computer connesso alla rete) non è abbastanza
> potente ed è da settimane che sta generando il render...e comunque non credo
> che la banda che ha a casa sia in grado di gestire un traffico dati così
> elevato :-/

Capisco che si tratta di una soluzione più complessa, ma se invece di usare i
tile precotti puntasse su mappe vettoriali renderizzate al volo, non potrebbe
riciclare i(l formato dei) file di OsmAnd?
O magari lo fa già/è nei piani.


Ciao
-- 
Luigi

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

Re: [Talk-it] [OSM wiki] Kerb

[Federico Cortese]

On Jul 6, 2016 12:18, "Cascafico Giovanni"  wrote:
>
> Ho abbozzato la traduzione nella pagina wiki [1] , ma mi viene il dubbio
se usare la parola cordolo oppure rampa... Magari dateci un'occhiata se
semanticamente é corretto.
>

È un Tag molto utile che ho usato spesso a Lecce. Secondo me va bene come
hai tradotto usando cordolo; poi è chiaro che dove il cordolo non ostacola
il passaggio (kerb=lowered o flush) ci possa essere una rampa.
Ciao
Federico
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Présentation

[dHuy Pierre]

Bienvenue!Hésite pas à poser tes questions ici si tu as des problèmes 
:)Librement, 

Le Mercredi 6 juillet 2016 12h43, Alain VASSAULT 
 a écrit :
 

 Hello la communauté. 
Je suis nouveau sur OSM et contribue surtout sur 2 villes Saint Martin du 
tertre dans l'yonne et Salins en seine et marne. 
J'apprends petit à petit comment taguer ceci puis cela. 
J'utilise comme outils JOSM sur mon pc et vespucci sur téléphone Android (qui 
fournit des traces gps en plus de servir à la cartographie).
J'espère en apprendre plus sur OSM et aider à mon maximum pour contribuer à 
remplir la carte. 

Amicalement, 

Tranquille

___
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] Tag 'network' et 'name' pour une relation de type route départementale

[François Lacombe]

Le 6 juillet 2016 à 12:47, JB  a écrit :

> Apparemment pas tant que ça :
> http://www.openstreetmap.org/user/SomeoneElse/diary/38988
> Par contre, gérer la double entrée sur les ways et relation, peut-être
> plus.
>

Parce qu'il ici, on passe par osm2pgql et c'est lui qui supporte la
conversion relation => chemin avec les bons attributs.
mapnik n'était peut-etre pas le bon exemple.

Ce que je voulais dire était que mapcss à lui tout seul n'était pas capable
de préciser une récupération de l'attribut depuis la relation dont le
chemin est membre.
Sur JOSM par exemple, bien que je ne sache pas comment c'est traité en
interne, ca ne marche pas.

Quoi qu'il en soit, la redondance sur ref=* n'est donc pas nécessaire,
merci pour l'info.



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

Re: [OSM-talk-fr] Présentation

[dHuy Pierre]

Bienvenue!Hésite pas à poser tes questions ici si tu as des problèmes 
:)Librement, 

Le Mercredi 6 juillet 2016 12h43, Alain VASSAULT 
 a écrit :
 

 Hello la communauté. 
Je suis nouveau sur OSM et contribue surtout sur 2 villes Saint Martin du 
tertre dans l'yonne et Salins en seine et marne. 
J'apprends petit à petit comment taguer ceci puis cela. 
J'utilise comme outils JOSM sur mon pc et vespucci sur téléphone Android (qui 
fournit des traces gps en plus de servir à la cartographie).
J'espère en apprendre plus sur OSM et aider à mon maximum pour contribuer à 
remplir la carte. 

Amicalement, 

Tranquille

___
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] Présentation

[Vincent de Château-Thierry]

Le 06/07/2016 12:41, Alain VASSAULT a écrit :

Hello la communauté.
Je suis nouveau sur OSM et contribue surtout sur 2 villes Saint Martin
du tertre dans l'yonne et Salins en seine et marne.
J'apprends petit à petit comment taguer ceci puis cela.
J'utilise comme outils JOSM sur mon pc et vespucci sur téléphone Android
(qui fournit des traces gps en plus de servir à la cartographie).
J'espère en apprendre plus sur OSM et aider à mon maximum pour
contribuer à remplir la carte.


La bienvenue Alain :)

vincent, voisin d'un autre Saint-Martin-du-Tertre 
(http://www.openstreetmap.org/node/26696127)


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

[OSM-ja] TelegramのOSMbot

[Shu Higashi]

東です。

Telegramというメッセンジャーをお使いの方はいらっしゃいますでしょうか。
https://telegram.org/

私は使ったことが無かったのですが
カタロニアのOSMコミュニティの方から
Telegram上で動作するOSMbotというものを作ったので翻訳してくれない？
という依頼があり、とりあえず日本語化してみました。
ご興味ありましたらお試しください。

アプリをインストールして電話番号を入れてショートメッセージで
認証コードをもらい、ログインします。
ログイン後に、話し相手として@OSMbotを探して問合せコマンドを
投げると答えが返ってくる、という流れです。

例えば
/help
とやるとコマンド一覧が返ってきます。
/setting
で言語設定できます。
/search 地物名
とやると該当するPOIが（複数）返ってきます。

AIとかでは*全く*なく、ごくシンプルなものです。
まだ安定していないようなので、バグレポートなどありましたら
こちらで連絡してみてください。
https://github.com/Xevib/osmbot
まぁ、正直なところ改良の余地はいっぱいあると思います :)

コマンドの説明などはこちら
https://github.com/Xevib/osmbot/wiki
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[JB]

Le 06/07/2016 à 11:45, François Lacombe a écrit :
Par contre sur la redondance ref sur le chemin et sur la relation, je 
croyais que c'était nécessaire pour le rendu ? (i.e mapnik ne sait pas 
aller chercher dans la relation pour dessiner le chemin et ne sait pas 
rendre des relations sur la base de la géométrie de ses membres).
Apparemment pas tant que ça : 
http://www.openstreetmap.org/user/SomeoneElse/diary/38988

Par contre, gérer la double entrée sur les ways et relation, peut-être plus.
JB.

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

[OSM-talk-fr] Présentation

[Alain VASSAULT]

Hello la communauté. 
Je suis nouveau sur OSM et contribue surtout sur 2 villes Saint Martin du 
tertre dans l'yonne et Salins en seine et marne. 
J'apprends petit à petit comment taguer ceci puis cela. 
J'utilise comme outils JOSM sur mon pc et vespucci sur téléphone Android (qui 
fournit des traces gps en plus de servir à la cartographie).
J'espère en apprendre plus sur OSM et aider à mon maximum pour contribuer à 
remplir la carte. 

Amicalement, 

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[Philippe Verdy]

L'ennui c'est que localement la référence change (on a des sections avec
des lettres supplémentaires qui font pourtant partie de l'itinéraire de la
départementale qui a la référence simplifiée. Cela survient notamment dans
les sections à sens de circulation séparés, parfois même à plus d'1
kilomètre d'écart (dans un sens on traverse un village, par une rue à sens
unique, dans l'autre on prend une bretelle de contournement... Ces deux
sections sont lettrées différemment, aucune des deux n'a la référence
simple de la départementale)

Le 6 juillet 2016 à 11:45, François Lacombe  a
écrit :

>
> Le 6 juillet 2016 à 11:33, JB  a écrit :
>
>> Pour ma part, je ne suis pas fan des relations non plus. Si elles sont
>> élégantes sur le plan de la modélisation, elles sont peu accessibles aux
>> nouveaux mappeurs. Attendez-vous à avoir des doublons ref sur la relation +
>> ref sur certains tronçons.
>>
>
> Vu la quantité de données croissante, les nouveaux mappeurs vont de plus
> en plus devoir s'adapter à une modélisation qui reste stricte pour
> organiser toute cette connaissance.
> On ne peut pas se passer des relations, mais on est pas obligé de
> commencer par ce domaine quand on arrive sur osm.
>
> Par contre sur la redondance ref sur le chemin et sur la relation, je
> croyais que c'était nécessaire pour le rendu ? (i.e mapnik ne sait pas
> aller chercher dans la relation pour dessiner le chemin et ne sait pas
> rendre des relations sur la base de la géométrie de ses membres).
> A moins que ça ait changé ou que je me trompe complètement ?
>
> François
>
> ___
> 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-it] [OSM wiki] Kerb

[Cascafico Giovanni]

Ho abbozzato la traduzione nella pagina wiki [1] , ma mi viene il dubbio se
usare la parola cordolo oppure rampa... Magari dateci un'occhiata se
semanticamente é corretto.

[1] http://wiki.openstreetmap.org/wiki/IT:Key:kerb

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[Philippe Verdy]

Aucun risque de doublon sur les tronçons, ici il s'agit juste d'une
relation "type=network" dont les membres sont les relations d'itinéraires
(type=route), il n'y a aucun chemin dedans.
C'est exactement comme les relations de réseaux de lignes de bus...
Le but étant aussi de lever des ambiguités sur les homonymies (références
souvent identiques quand une ancienne nationale passe d'un département à
l'autre). Souvent les anciennes nationales sont à deux chiffres, en
devenant départementales un chiffre des centaines a été inséré et s'il n'y
a pas de conflit avec une autre départementale c'est le même entre les deux
départements (cela simplifie la navigation). mais des conflits existent et
alors on a des centaines différentes, et une autre référence ailleurs.
D'autre part cela facilite beaucoup la maintenance des numérotations en
ayant une vue globale de toutes les départementales d'un départment. Et vu
l'échelle (un département entier) ce n'est pas toujours simple de les
distinguer visuelement et des recherches peuvent ne pas indiquer quel
département est concerné par un numro trouvé (la recherche simple ne
retourne pas dans les listes non plus les noms de communes et il y a des
tas de routes qui chevauchent plusieurs départements, en sortent et y
reviennent sur une courte distance).
Bref le numéro de référence ne suffit pas, il faut toujours une autre
information.

Le 6 juillet 2016 à 11:33, JB  a écrit :

> Bonjour,
> Personnellement, je ne suis pas convaincu par le name=*. Pour moi, le ref
> suffit largement, ce que tu mets dans name est juste une description de ce
> ref.
> Pour ma part, je ne suis pas fan des relations non plus. Si elles sont
> élégantes sur le plan de la modélisation, elles sont peu accessibles aux
> nouveaux mappeurs. Attendez-vous à avoir des doublons ref sur la relation +
> ref sur certains tronçons.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-au] Possible illegal imports in Western Australia

[Andrew Harvey]

I notice aaronsta already reverted 40195731 so I tried to revert

40195392
40195333
40195330
40195315
40171955
40066399
40065907
40065268
40064728
40064280
40053210
40052929
40052639
40052416
40052185
40051946
40051763

These ones worked 40195392 40195315 40195330 40195333 40171955
40053210 but the rest I got errors
GET https://api.openstreetmap.org/api/0.6/changeset/40051763/download...
408 Request Timeout (17b) so they didn't revert.

On 5 July 2016 at 21:39, cleary  wrote:
>
> I don't have the knowledge to run scripts safely, so it would be good if you
> could do this.  Thanks.
>
>
>
>
> On Tue, Jul 5, 2016, at 09:34 PM, Andrew Harvey wrote:
>
>
> On 5 Jul 2016 8:26 PM, "cleary"  wrote:
>
>> I have been looking at some South Australian administrative boundaries.
>> The South Australia / Western Australia border is a bit messy and I was
>> looking to see it I could sort it out. I realised that some of the data
>> is part of the recently reported illegal imports of WA data - includes
>> some LGA and locality boundaries. Not sure I can solve the border issue
>> completely but I am uncomfortable about the illegal data. Is it OK to
>> delete recently added WA Government data from this user, aaronsta ?
>
> I was hoping Data Working Group could help out by removing the history since
> this that appears to be infringing copyright. However in the meantime maybe
> we should just revert which at least means it's not directly visible.
>
> I would steer clear of manual work, and try to run a revert script. I had
> luck with the woodpeck revert scripts. Did you want to do this, or want me
> to have a go?
>
>

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[François Lacombe]

Le 6 juillet 2016 à 11:33, JB  a écrit :

> Pour ma part, je ne suis pas fan des relations non plus. Si elles sont
> élégantes sur le plan de la modélisation, elles sont peu accessibles aux
> nouveaux mappeurs. Attendez-vous à avoir des doublons ref sur la relation +
> ref sur certains tronçons.
>

Vu la quantité de données croissante, les nouveaux mappeurs vont de plus en
plus devoir s'adapter à une modélisation qui reste stricte pour organiser
toute cette connaissance.
On ne peut pas se passer des relations, mais on est pas obligé de commencer
par ce domaine quand on arrive sur osm.

Par contre sur la redondance ref sur le chemin et sur la relation, je
croyais que c'était nécessaire pour le rendu ? (i.e mapnik ne sait pas
aller chercher dans la relation pour dessiner le chemin et ne sait pas
rendre des relations sur la base de la géométrie de ses membres).
A moins que ça ait changé ou que je me trompe complètement ?

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[Vincent de Château-Thierry]

Bonjour,

Le 06/07/2016 11:33, JB a écrit :


Personnellement, je ne suis pas convaincu par le name=*. Pour moi, le
ref suffit largement, ce que tu mets dans name est juste une description
de ce ref.


D'accord avec ça. Autant garder le name=* pour de vrais noms de portions 
routières comme par exemple 
https://en.wikipedia.org/wiki/Route_Napol%C3%A9on



Pour ma part, je ne suis pas fan des relations non plus. Si elles sont
élégantes sur le plan de la modélisation, elles sont peu accessibles aux
nouveaux mappeurs. Attendez-vous à avoir des doublons ref sur la
relation + ref sur certains tronçons.


Ça peut se justifier si la relation a des attributs en propre, 
factorisant ce qui peut l'être. Mais comme pour les associatedStreet 
finalement, c'est juste une modélisation possible et pas un passage obligé.


Sinon même remarque que Francescu concernant le is_in : on doit pouvoir 
s'en passer (litote).


vincent

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[François Lacombe]

+1 Avec Francescu sur le is_in : on a les relations pour ça, à minima
l'analyse spatiale.

Également sur le fait de traduire une arborescence dans les tags, c'est pas
forcément adapté.
Ici la route départementale est effectivement dans un périmètre fermé
correspondant à la région, inutile de le faire transparaitre dans le code.
Ajouter ces infos dans les tags facilite la recherche c'est certain, mais
ça pose autant de problèmes pour la maintenance (cf fusion des régions).
Parce qu'on pourrait faire pareil avec le millefeuille : canton,
arrondissement... Et aussi on aurait du mal à traduire un cas où une route
quelle qu'elle soit est partagée sur plusieurs territoires.

Si des codes ISO sont disponibles, autant les utiliser sans inventer autre
chose
Et dans ces codes ISO si il y a le code pays, région ou autre, ca devient
le problème de l'ISO et pas celui d'OSM.

Il y a un compromis à trouver entre grouper des objets selon une valeur de
tag et utiliser une relation.
Ta proposition 1.5 est intéressante. Si je comprends bien, tu indiquerais
network=* sur cette méta-relation ?
Résultat quand deux départements fusionnent : un seul objet à modifier et
pas 300. L'édition de cet unique objet est cependant peu aisée vu le nombre
de membres potentiel (question d'habitude).
Idem sur les lignes de transport en commun... et tout autre réseau.

Par contre, est-ce ok de mettre des éléments routiers dans la relation
administrative du département, avec au moins les frontières et probablement
des écoles, des établissements sportifs et autres ?
C'est à dire que dès qu'on veut récupérer les contours d'un département, on
récupère vraiment tout si on ne filtre pas.


A+

François


*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

Le 6 juillet 2016 à 09:56, Francescu GAROBY  a écrit :

> Beau travail auquel tu t'attaques !
> J'ai moi-même commencé à faire la même chose avec les RT (routes
> territoriales) de Corse (anciennes RN). Je vais donc suivre attentivement
> cette discussion !
>
> Et sinon, je déconseille l'usage du tag "is_in", qui n'a plus de sens
> maintenant que les recherches géographiques sont possibles.
>
>
> Francescu
>
> Le 6 juillet 2016 à 09:15, Topographe Fou  a
> écrit :
>
>> Bonjour,
>>
>> Merci pour ce premier retour.
>>
>> Pour le 1.2 en effet je voulais parler des codes INSEE du département et
>> de celui de la région. Je partage également le point de vue que cela ne
>> contient pas plus d'informations dans le cas des RD. Mais si on se place
>> dans une logique d'arborescence alors il pourrait être pratique de faire
>> des recherches ou filtres par région. Hiérarchiquement parlant entre le
>> pays et le département il y a une région :). Il y a une solution
>> peut-être la plus logique (voir après).
>>
>> Proposition 1.4 : network=FR:78 (cad c'est une route départementale des
>> Yvelines en France) + is_in=FR:11:78 (cad c'est une relation dans le
>> département des Yvelines, région IDF, en France). Is_in est pas mal utilisé
>> aux EU, pour un statut assez vague.
>>
>> Proposition 1.5 : mettre les relations RD membre de la relation
>> Département pour créer explicitement la hiérarchie + network=FR:78
>>
>> Ok pour l'avis sur le 2.
>>
>> Pour le 'operator' je le préciserai sur le Wiki au moment de faire la
>> synthèse.  En ce qui me concerne cela sort de mon périmètre.
>>
>> LeTopographeFou
>> *De:*fl.infosrese...@gmail.com
>> *Envoyé:*6 juillet 2016 8:05 AM
>> *À:*talk-fr@openstreetmap.org
>> *Répondre à:*talk-fr@openstreetmap.org
>> *Objet:*Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de
>> type route départementale
>>
>> Hello,
>>
>> Bonne initiative, ça va en effet permettre de significativement améliorer
>> la qualité des données de routage, avec un bon impact sur les rendus
>> routiers
>>
>> Deux remarques pour amener de l'eau a ton moulin :
>> Point 1.2 : tu devais vouloir parler de l'INSEE région ? Inutile selon
>> moi, c'est bien un réseau départemental. Si on veut l'INSEE région, on le
>> trouve via l'INSEE du département
>> Point 2.3 : En effet, il ne faut pas refonder inutilement l'info et cette
>> solution de passer par network=* est la meilleure sur ce plan.
>>
>> Autre chose : il faudrait utiliser operator=* pour indiquer l'exploitant,
>> idéalement sur chaque segment de route, puisque l'exploitation des tronçons
>> urbain peut être délégué aux villes.
>>
>> A+
>>
>> François
>> Le 6 juil. 2016 12:25 AM, "LeTopographeFou" 
>> a écrit :
>>
>> Bonjour,
>>
>> J'ai attaqué un imposant chantier visant à améliorer la prise en compte
>> des Routes Départementales (RD) françaises dans OSM. Ce chantier vise à :
>>
>>1. Faire qu'il y ait une relation par RD par département (ex :
>>http://www.openstreetmap.org/relation/6335278)
>>2. Vérifier et corrigé le tracé des RD
>>
>> Le tout étant fait *à la main* (j'insiste sur le 

[OSM-Talk-ZA] Fwd: WiFi Hotspots in SA

[Michael Graaf]

-- Forwarded message --
From: *Michael Graaf* 
Date: Wednesday, July 6, 2016
Subject: WiFi Hotspots in SA
To: "impo...@openstreetmap.org" ,
talk...@openstreetmaps.org


Greetings all,

I write on behalf of a team preparing to create an app (free as in beer as
well as in speech) which will help users find WiFi hotspots and also review
them or report new ones. We already have some data-sets which appear to be
public-domain, but these things keep changing hence our intention to have
real-time crowdsourcing.

Initially we thought of using both Google Maps and OSM but on closer
investigation, discovered that above a minimal level of use, Google API
costs some dollars, so we discarded that idea.

None of us has done this kind of thing before so we are hoping for guidance
and assistance. I found your addresses in the OSM Import Guidelines page.

yours in anticipation,

Michael Graaf.
___
Talk-ZA mailing list
Talk-ZA@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-za

Re: [Talk-cz] Špatná velikost písmen v názvech ulic importovaných z UIR-ADR

[Karel Volný]

...
> Koukám že RUIAN obsahuje formulář pro zasílání oprav [1]. Obsahuje tam ale
> vtipnou poznámku: "Návrhy na změny velikosti písmen budou zamítnuty
> automaticky."
> 
> Co to sakra je?

to je přesně tohle:

"Starší způsob psaní často odůvodňují tím, že změna by pro ně byla finančně 
náročná."

- tu nahlášenou chybu musí někdo zpracovat ... sám jsi napsal, že je to v řádu 
deset tisíc jenom v Praze

(a vůbec bych se nedivil, kdyby to bylo i tak trochu na truc vůči těm koninám, 
co jazykovědci vymýšlí)

K.


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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[JB]

Bonjour,
Personnellement, je ne suis pas convaincu par le name=*. Pour moi, le 
ref suffit largement, ce que tu mets dans name est juste une description 
de ce ref.
Pour ma part, je ne suis pas fan des relations non plus. Si elles sont 
élégantes sur le plan de la modélisation, elles sont peu accessibles aux 
nouveaux mappeurs. Attendez-vous à avoir des doublons ref sur la 
relation + ref sur certains tronçons.

JB.

Le 06/07/2016 à 00:28, LeTopographeFou a écrit :

Bonjour,

J'ai attaqué un imposant chantier visant à améliorer la prise en 
compte des Routes Départementales (RD) françaises dans OSM. Ce 
chantier vise à :


 1. Faire qu'il y ait une relation par RD par département (ex :
http://www.openstreetmap.org/relation/6335278)
 2. Vérifier et corrigé le tracé des RD

Le tout étant fait _à la main_ (j'insiste sur le fait qu'il n'y a pas 
d'automate) en comparant les données OSM avec Route500. A ce jour j'ai 
fais les Yvelines et attaque l'Essonne. Aucune des RD n'avait de 
relation ad-hoc et certaines n'étaient carrément pas (ou 
incomplètement) référencées par leurs champ ref=*. Donc je les attaque 
une à une avec de belles trouvailles.


Pour le moment je mets 4 tags à chaque relations (cf. 
http://www.openstreetmap.org/relation/6335278) mais je ne trouve pas 
cela très optimal d'où deux points à vous soumettre :


 1. Il faudrait en profiter pour mettre un tag 'network'. Pour info
les RN ont visiblement un tag 'network=FR:n-road'. Afin de coller
avec la logique utilisées aux EU j'ai deux propositions à faire :
 1. Utiliser le code pays et le code INSEE du département (en
l’occurrence cela ferait 'FR:78')
 2. Faire comme précédemment mais avec également le code INSEE du
département (en l’occurrence cela ferait 'FR:11:78)
 3. Utiliser le code ISO 3166-2 (en l’occurrence cela ferait 'FR-78')
 2. Concernant le tag 'name' il y a des risques d'amalgames entre deux
départements. Est-il judicieux d'y mentionner le nom du
département ? Le hic est que, rigoureusement parlant, le nom
"officiel" est 'Route départementale 29' sans autre fioriture
 1. Exemple 1 : 'Route départementale 29 (Yvelines)' => clair et
concis, facile à parser
 2. Exemple 2 : 'Route départementale des Yvelines 29' => bof
 3. Autre solution : ne rien faire, se dire que l'ajout de
'network' suffit et que si amalgame il y a c'est un problème à
gérer par l'éditeur/l'app et non par le cartographe => c'est
ma solution préféré mais autant réfléchir avant d'aller plus loin.

A ce jour je ne vois pas de réponse ni dans les relations existantes 
ni sur le wiki. Qu'en pensez-vous ?


LeTopographeFou



___
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] Max speed forward/backward

[Shaun McDonald]

ITO Map shows the split speed limits: 
http://product.itoworld.com/map/124?lon=-112.18642=33.53122=18 


Shaun
(ITO World developer)
> On 6 Jul 2016, at 10:05, Hans De Kryger  wrote:
> 
> http://www.openstreetmap.org/way/399867361#map=19/33.53112/-112.18568 
> 
> 
> Regards,
> Hans
> 
> On Wed, Jul 6, 2016 at 1:51 AM, Shaun McDonald  > wrote:
> Hi Hans,
> 
> Do you have an example that you have mapped?
> 
> Shaun
> 
>> On 5 Jul 2016, at 22:09, Hans De Kryger > > wrote:
>> 
>> Thanks Paul.
>> 
>> There's a lot of split speed limits here in the valley (Arizona.) I've 
>> worked hard mapping quite a few. Would love for more services to show them.
>> 
>> 
>> On Jul 5, 2016 2:41 AM, "Paul Johnson" > > wrote:
>> On Sun, Jul 3, 2016 at 6:10 PM, Hans De Kryger > > wrote:
>> 
>> 
>> ​Anyone know of any apps or services that display​ max speed 
>> forward/backward tags. I assume most don't know how to?
>> 
>> I know that Osmand will as I've seen it come up on some odd edge cases where 
>> sign placement is weird (normally Oklahoma doesn't do these split limits 
>> unless it's not feasible to signpost the limits in the same spot both 
>> directions).  Someone up towards Colorado should have more exact 
>> information, as split limits are routine in that state.
>> 
>> ___
>> talk mailing list
>> talk@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk 
>> 
>> 
>> 
>> ___
>> talk mailing list
>> talk@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk 
>> 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Ubuntu Touch e OpenStreetMap

[Martin Koppenhoefer]

sent from a phone

> Il giorno 06 lug 2016, alle ore 09:17, Aury88  ha 
> scritto:
> 
> stando al wiki di OSM per accedere al
> servizio "interno" tile di OSM bisogna fare formale richiesta che deve venir
> valutata in funzione del traffico...come mai usando leaflet o openlayer lo
> stesso servizio tile di osm viene fornito senza remore?


non è così, se generi traffico sopra un livello sopportabile vieni bloccato. 
Per usare i tiles da osm viene richiesto l'uso di una stringa che identifichi 
la tua app in maniera univoca e pertinente


> 
> Marcos sta provando a mettere in piedi un sistema di mappe offline e
> realizzare un proprio tile server, ma ha risorse limitate e il suo computer
> home server (un vecchio computer connesso alla rete) non è abbastanza
> potente ed è da settimane che sta generando il render...e comunque non credo
> che la banda che ha a casa sia in grado di gestire un traffico dati così
> elevato :-/


potrebbe chiedere a qualcuno come Mapbox se volessero sponsorizzare il suo 
progetto, oppure trovare degli sponsor per pagare qualcuno che gli fornisca i 
tiles o finanzia un server ed il traffico per generare e distribuire i propri 
tiles.

In ambito osm non si usano molto i sistemi WMS, al solito si usa un sistema più 
semplice "proprietario" (formalmente non è nemmeno un TMS), perché quasi tutti 
i tiles sono soltanto disponibili in spherical mercator e in livelli di zoom 
predefiniti (WMS è più versatile ma quella flessibilità per lo più non è 
richiesta dalla nostra tipologia di utente, e non offrendo proiezioni 
differenti e zoom variabili si può distribuire più tiles con meno risorse, un 
sistema introdotto da Google, credo)

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

Re: [Talk-cz] Špatná velikost písmen v názvech ulic importovaných z UIR-ADR

[Lukáš Karas]

Dne středa 6. července 2016 10:54:30 CEST Mirek Dlask napsal(a):
> Ahoj,
> už ten nadpis máš špatně. Pro import aktualizaci adres se už dost dlouho
> používá RUIAN. http://vdp.cuzk.cz/

Dobrá. To není zas tak podstatné. Vycházel jsem z tagu source:addr=uir_adr

> Chybějící adresy se sice už řešily, ale jak je vidět nevyřešily. Na vině je
> rozpor mezi stavovým výpisem (měsíčně) a aktualizacemi ve výměnném formátu
> RUIAN.
> Co to je špatná velikost písmen?  http://prirucka.ujc.cas.cz/?id=186 kde se
> píše.

Nejsem grammar nazi. Stejně tak chápu že pokud si například zastupitelé v 
Litomyšli odhlasují že se bude jejich město jmenovat "LyTomišl" tak bychom to 
měli v OSM datech upravit. Ale tady jde o očividnou chybu v RUIAN datech. 
Ve všech materiálech Prahy 3 se ulice "Pod Lipami" píše s velkým "L" (stejně 
tak ostatní). V RUIANu je ale s malým písmenem. Neřešil bych to, kdyby to 
nedělalo problémy v OSM Scout knihovně, která se snaží vytvořit index adres 
jako stromovou strukturu.

> 
> PČP jsou závazná pouze pro školní jazykovou výuku. Pro ostatní uživatele
> češtiny mají jen formu doporučení. Některé obecní, městské úřady
> a magistráty stále setrvávají u staršího způsobu psaní, zejména pokud jde
> o předložková spojení (viz bod 2.1
> ). Starší způsob psaní
> často odůvodňují tím, že změna by pro ně byla finančně náročná.
> 
> Tedy. Ve škole musíš PČP dodržovat, pokud zasedneš v obecní komisi pro
> pojmenování ulic, můžeš se na pravidla vybodnout.
> 
> Dne 6. července 2016 9:41 Lukáš Karas  napsal(a):
> > Ahoj, možná se toto téma již v listu řešilo, ale žádné vlákno jsem
> > nenašel.
> > Případně mě omluvte.
> > 
> > Píšu aplikaci nad knihovnou OSM Scout, při importu Česka jsem si všiml že
> > ve
> > výsledné databázi chybí mnoho adres. Po dalším zkoumání jsem zjistil že
> > hodnota "addr:street" neodpovídá žádné blízké ulici (knihovna se snaží z
> > adres
> > vytvořit stromovou strukturu, pokud nenajde odkazovanou ulici, náměstí
> > nebo
> > sídliště..., adresu nepřidá do databáze). Po dalším zkoumání jsem zjistil
> > že
> > mnoho adresních bodů má špatnou velikost písmen v tagu "addr:street",
> > například v ulici "V Olšinách" je mnoho (96) adres které mají ulici
> > uvedenou
> > jako "V olšinách".
> > 
> > Hledání ulic jsem v knihovně udělal chytřejší, aby ignorovalo velikost
> > písmen.
> > Nevím ale jestli její autor přijme merge request. V každém případě si
> > myslím
> > že data v OSM by měla být opravena. Ale není to na ruční práci, jen v
> > Praze
> > jsem našel 10 tisíc záznamů. Je tu někdo by byl schopný napsat automatický
> > script? Mohu dodat log z importu kde jsou chyby vypsány...
> > 
> > Lukáš
> > 
> > ___
> > Talk-cz mailing list
> > Talk-cz@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz

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

[Talk-cz] data o rozmístění záchranných podkov

[Karel Volný]

ahoj,

měl bych prosbičku za projekt OpenStreetMap - rádi bychom zanesli do mapy 
rozmístění záchranných prostředků

chtěl bych se tedy zeptat, jestli existuje nějaká databáze, kde se na jezech 
dělala bezpečnostní opatření, a zda bychom z ní mohli dostat rozmístění 
záchranných podkov a informačních cedulí včetně jejich referenčních údajů, 
které se tam uvádí pro HZS, případně dalšího, co by stálo za zmapování?

OpenStreetMap zpracovává data pod licencí ODbL[*], je tedy třeba s touto 
souhlasit (přímo na nebezpecnejezy.cz nic o copyrightu nevidím?)

K.

[*] viz http://www.openstreetmap.org/copyright

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

Re: [Talk-cz] traumabody v OSM

[Mirek Dlask]

OK, tak jdu na tom zapracovat. Ty tři bodíky co jsem přidal včera dotaguju
ještě o emergency=access_point.
Zjistil jsem totiž, že Osmand mi je najde, na rozdíl od highway=* .
Navíc je jich v OSM většina  tagovaná oběma způsoby.
Je otázka, jestli nedoplnit emergency i pro další body alespoň v ČR.

Na wiki nemám přístup, protože NAT ...

Dne 6. července 2016 10:57 Karel Volný  napsal(a):

> zdar,
>
> >1. Je to stále "Návrh: Náhrada značky highway=emergency_access_point"
> -
> >viz wiki?
>
> já nevím, jak to aktuálně po formální stránce funguje, přijde mi spíš, že v
> posledních letech nefunguje ... visí to tam dva roky a nic se neděje ...
>
> >2. Proč nemáme ve wiki jednu možnost respektive preferovanou možnost?
>
> protože to tam nikdo nenapsal :-)
>
> >3. Od návrhu (2008) poměr 18556:670 ve prospěch
> >highway=emergency_access_point. Ze 670 jich je drtivá většina v
> Německu.
>
> je hodně pravděpodobné, že osm let staré tagování bude mít více výskytů než
> dva roky starý návrh - pokud se nedospělo k dohodě o hromadné záměně
>
> vzhledem k tomu, jak to (ne)funguje, ono "mávnutí kouzelného proutku",
> kterým
> se to změní, bych neočekával, a tím spíše bych prostě začal používat
> tagování
> nové, a tím v jeho prospěch změnil výše uvedený poměr
>
> pokud bychom se měli řídit jen tím, čeho je víc, co je zavedenější, tak se
> nezmění nikdy nic, to je de facto zdůvodnění kruhem, je toho hodně, tak to
> použijeme, a tím, že to použijeme, toho bude ještě víc, a protože je toho
> víc,
> je důvod to používat atd.
>
> já nejsem příznivcem toho, aby se furt něco předělávalo a dělaly změny jen
> pro
> změny, ba právě naopak, ale v tomto konkrétním případě mi to dává smysl,
> protože 'highway' považuji za principiálně špatně - a v tom původním
> hlasování
> se s tou námitkou nikdo pořádně nevypořádal
>
> jediný argument, co v diskusi padl, je, že by tam měla vést cesta, když
> tam má
> dojet sanitka, a tudíž že je to podobné jako bus_stop, ale to je s
> prominutím
> blbost - jednak tam vůbec cesta být nemusí (proč sanitka, může to být u
> místa
> vhodného k přistání vrtulníku), a jednak bus_stop je skutečně vlastností té
> silnice (má to vliv na dopravu, je tam ostrůvek, záliv, značka, whatever),
> zatímco ten access_point nic takového neimplikuje, je to cedule jako
> kterákoliv jiná (rozcestníky taky tagujeme information=guidepost a ne
> highway=guidepost), případně je u toho ještě něco dalšího jako
>
> > U nás nula. Od jakého počtu se dá tag označit za "slušně zavedený?
>
> mluvil jsem o klíči 'emergency', nikoliv o jeho konkrétní hodnotě
> 'access_point'
>
> všimni si, že se tak taguje spousta užitečných věcí, jako třeba umístění
> veřejných defibrilátorů, záchranné kruhy atp., do čehož ten access_point
> IMO
> krásně zapadá - viz
> http://wiki.openstreetmap.org/wiki/Key:emergency_(facilities)
>
> - mimochodem, je-li řeč o záchranných kruzích, v rámci projektu
> nebezpecnejezy.cz jsou krom záchranných prostředků instalovány i cedule
> obsahující mj. název, říční kilometr a souřadnice, kteréžto pro HZS plní
> přesně tuto funkci ... což je krásný příklad, jak je to 'highway' absolutně
> mimo, neb často jsou umístěny přímo na konstrukci jezu (její pobřežní
> části),
> a ke spoustě jezů žádná cesta nevede
>
> ... a jdu napsat Petrovi jestli nám dá data
>
> > 4. JOSM emergency=access_point nezná.
>
> https://josm.openstreetmap.de/newticket ;-)
>
> > Sečteno podtrženo - záměr dobrý, provedení nic moc.
>
> tož je potřeba na tom provedení zapracovat, že :-)
>
> K.
>
> ___
> 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] Max speed forward/backward

[Hans De Kryger]

http://www.openstreetmap.org/way/399867361#map=19/33.53112/-112.18568

*Regards,*

*Hans*

On Wed, Jul 6, 2016 at 1:51 AM, Shaun McDonald 
wrote:

> Hi Hans,
>
> Do you have an example that you have mapped?
>
> Shaun
>
> On 5 Jul 2016, at 22:09, Hans De Kryger  wrote:
>
> Thanks Paul.
>
> There's a lot of split speed limits here in the valley (Arizona.) I've
> worked hard mapping quite a few. Would love for more services to show them.
>
> On Jul 5, 2016 2:41 AM, "Paul Johnson"  wrote:
>
> On Sun, Jul 3, 2016 at 6:10 PM, Hans De Kryger 
> wrote:
>
>>
>>
>> ​Anyone know of any apps or services that display​ max speed
>> forward/backward tags. I assume most don't know how to?
>>
>
> I know that Osmand will as I've seen it come up on some odd edge cases
> where sign placement is weird (normally Oklahoma doesn't do these split
> limits unless it's not feasible to signpost the limits in the same spot
> both directions).  Someone up towards Colorado should have more exact
> information, as split limits are routine in that state.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-is] Quality assurance : Public toilets

[Morten Lange]

Sæl aftur,
Min mistök. Klósett  þétt við jöklinum í, þjóðgarðinum  :-) 
 -- 
Regards / Kveðja / Hilsen Morten Lange, Reykjavík

  From: Morten Lange 
 To: OpenStreetMap In Iceland  
 Sent: Tuesday, 5 July 2016, 23:59
 Subject: Quality assurance : Public toilets
   
Hæ 

Hef grunsemdir um að sumum af þessum snyrtingum séu á röngum stað ...  ( uppi á 
jökli ) 

http://overpass-turbo.eu/s/h9V Hvað gerum við í þessu. Hvernig er hægt að gera 
betur í að trygja gæði ? 

-- 
 Regards / Kveðja / Hilsen Morten Lange, Reykjavík

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

Re: [talk-au] Legal access to Public land ...

[Warin]

On 7/5/2016 9:13 AM, Mark Pulley wrote:

On 2 Jul 2016, at 3:30 pm, Warin <61sundow...@gmail.com> wrote:


On 7/2/2016 9:26 AM, Frank wrote:

OpenStreetMap Wiki page Australian Tagging Guidelines has been
changed on 1 July 2016 by Swanilli to say that the public has a legal right to 
access public land ...

No!

The NSW NPSW do legally exclude the public from certain areas and at least 
vehicles from certain tracks.

The NSW, WA, SA and Victorian State Forests legally exclude the public too .. 
think about the car rallies held from time to time.

Even 'public roads' get closed to the public from time to time... how else 
would the Bathurst Road Race be held?

I have remove the offending statement from the wiki. I did attempt to contact 
the user .. but the wiki page has no send a message' type thiny ...  hence this 
message.

Found the contact ... made comments on 2 changesets.
Confusion may have arisen over plain English understanding of
access=no

But the tags are
access=no
foot=yes

meaning you can access by foot but nothing else... in the OSM data base.


I have been using

motor_vehicle=no (or motorcar=no / motorcycle=no)
foot=yes (or foot=designated)

and depending on other tags

bicycle=no (or bicycle=designated if specifically signposted)

Mark P.



Thanks Mark. That is a good method...

I'd use motor_vehicle as that covers trucks, tractors etc.

On review I think something for the Oz wiki tagging guide lines page 
http://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines#Access_roads_on_public_land
  along the lines of

"Where an access road crosses public land it should not be assumed to have or not have 
access restrictions. Where a sign says "Authorised vehicles Only" or you know that 
access is restricted the tag motor_vehicle=private could be used to indicate the access 
restriction.
Access restrictions for others (walkers, cyclists etc.) should be found on the 
access wiki page (link to http://wiki.openstreetmap.org/wiki/Key:access).
To help other mappers recognise the validity of the access restriction a sourec tag 
can be used e.g. source:access_motor_vehicle=sign on eastern end of road"

 




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

Re: [Talk-cz] traumabody v OSM

[Karel Volný]

zdar,

>1. Je to stále "Návrh: Náhrada značky highway=emergency_access_point" -
>viz wiki?

já nevím, jak to aktuálně po formální stránce funguje, přijde mi spíš, že v 
posledních letech nefunguje ... visí to tam dva roky a nic se neděje ...

>2. Proč nemáme ve wiki jednu možnost respektive preferovanou možnost?

protože to tam nikdo nenapsal :-)

>3. Od návrhu (2008) poměr 18556:670 ve prospěch
>highway=emergency_access_point. Ze 670 jich je drtivá většina v Německu.

je hodně pravděpodobné, že osm let staré tagování bude mít více výskytů než 
dva roky starý návrh - pokud se nedospělo k dohodě o hromadné záměně

vzhledem k tomu, jak to (ne)funguje, ono "mávnutí kouzelného proutku", kterým 
se to změní, bych neočekával, a tím spíše bych prostě začal používat tagování 
nové, a tím v jeho prospěch změnil výše uvedený poměr

pokud bychom se měli řídit jen tím, čeho je víc, co je zavedenější, tak se 
nezmění nikdy nic, to je de facto zdůvodnění kruhem, je toho hodně, tak to 
použijeme, a tím, že to použijeme, toho bude ještě víc, a protože je toho víc, 
je důvod to používat atd.

já nejsem příznivcem toho, aby se furt něco předělávalo a dělaly změny jen pro 
změny, ba právě naopak, ale v tomto konkrétním případě mi to dává smysl, 
protože 'highway' považuji za principiálně špatně - a v tom původním hlasování 
se s tou námitkou nikdo pořádně nevypořádal

jediný argument, co v diskusi padl, je, že by tam měla vést cesta, když tam má 
dojet sanitka, a tudíž že je to podobné jako bus_stop, ale to je s prominutím 
blbost - jednak tam vůbec cesta být nemusí (proč sanitka, může to být u místa 
vhodného k přistání vrtulníku), a jednak bus_stop je skutečně vlastností té 
silnice (má to vliv na dopravu, je tam ostrůvek, záliv, značka, whatever), 
zatímco ten access_point nic takového neimplikuje, je to cedule jako 
kterákoliv jiná (rozcestníky taky tagujeme information=guidepost a ne 
highway=guidepost), případně je u toho ještě něco dalšího jako

> U nás nula. Od jakého počtu se dá tag označit za "slušně zavedený?

mluvil jsem o klíči 'emergency', nikoliv o jeho konkrétní hodnotě 
'access_point'

všimni si, že se tak taguje spousta užitečných věcí, jako třeba umístění 
veřejných defibrilátorů, záchranné kruhy atp., do čehož ten access_point IMO 
krásně zapadá - viz 
http://wiki.openstreetmap.org/wiki/Key:emergency_(facilities)

- mimochodem, je-li řeč o záchranných kruzích, v rámci projektu 
nebezpecnejezy.cz jsou krom záchranných prostředků instalovány i cedule 
obsahující mj. název, říční kilometr a souřadnice, kteréžto pro HZS plní 
přesně tuto funkci ... což je krásný příklad, jak je to 'highway' absolutně 
mimo, neb často jsou umístěny přímo na konstrukci jezu (její pobřežní části), 
a ke spoustě jezů žádná cesta nevede

... a jdu napsat Petrovi jestli nám dá data

> 4. JOSM emergency=access_point nezná.

https://josm.openstreetmap.de/newticket ;-)

> Sečteno podtrženo - záměr dobrý, provedení nic moc.

tož je potřeba na tom provedení zapracovat, že :-)

K.


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

Re: [Talk-cz] Špatná velikost písmen v názvech ulic importovaných z UIR-ADR

[Mirek Dlask]

Ahoj,
už ten nadpis máš špatně. Pro import aktualizaci adres se už dost dlouho
používá RUIAN. http://vdp.cuzk.cz/
Chybějící adresy se sice už řešily, ale jak je vidět nevyřešily. Na vině je
rozpor mezi stavovým výpisem (měsíčně) a aktualizacemi ve výměnném formátu
RUIAN.
Co to je špatná velikost písmen?  http://prirucka.ujc.cas.cz/?id=186 kde se
píše.

PČP jsou závazná pouze pro školní jazykovou výuku. Pro ostatní uživatele
češtiny mají jen formu doporučení. Některé obecní, městské úřady
a magistráty stále setrvávají u staršího způsobu psaní, zejména pokud jde
o předložková spojení (viz bod 2.1
). Starší způsob psaní
často odůvodňují tím, že změna by pro ně byla finančně náročná.

Tedy. Ve škole musíš PČP dodržovat, pokud zasedneš v obecní komisi pro
pojmenování ulic, můžeš se na pravidla vybodnout.

Dne 6. července 2016 9:41 Lukáš Karas  napsal(a):

> Ahoj, možná se toto téma již v listu řešilo, ale žádné vlákno jsem nenašel.
> Případně mě omluvte.
>
> Píšu aplikaci nad knihovnou OSM Scout, při importu Česka jsem si všiml že
> ve
> výsledné databázi chybí mnoho adres. Po dalším zkoumání jsem zjistil že
> hodnota "addr:street" neodpovídá žádné blízké ulici (knihovna se snaží z
> adres
> vytvořit stromovou strukturu, pokud nenajde odkazovanou ulici, náměstí nebo
> sídliště..., adresu nepřidá do databáze). Po dalším zkoumání jsem zjistil
> že
> mnoho adresních bodů má špatnou velikost písmen v tagu "addr:street",
> například v ulici "V Olšinách" je mnoho (96) adres které mají ulici
> uvedenou
> jako "V olšinách".
>
> Hledání ulic jsem v knihovně udělal chytřejší, aby ignorovalo velikost
> písmen.
> Nevím ale jestli její autor přijme merge request. V každém případě si
> myslím
> že data v OSM by měla být opravena. Ale není to na ruční práci, jen v Praze
> jsem našel 10 tisíc záznamů. Je tu někdo by byl schopný napsat automatický
> script? Mohu dodat log z importu kde jsou chyby vypsány...
>
> Lukáš
>
> ___
> 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] School project Ghana

[Oleksiy Muzalyev]

On 05/07/16 23:28, Alert Bouterse wrote:


...

Open Street Maps Ghana is looking for educational material like 
(prinable / ofline) workbooks to educate children on JHS and SHS 
schools. ...



Hello Alert Bouterse,

The official language in Ghana is English [1], so here are some books in 
English:


http://wiki.openstreetmap.org/wiki/Books

http://stevecoast.com/2015/11/05/the-book-of-osm-now-available/

You may buy a copy of each, read, and see if it is suitable as a 
textbook. I just mapped a couple of buildings in the town of Tarkwa, a 
centre of gold mining and manganese mining, in Ghana. There is an 
excellent satellite imagery for this town and many good buildings are 
not mapped yet. So students can also do a valuable work of mapping as a 
practical part of a course.


[1] https://en.wikipedia.org/wiki/Ghana

Best regards,

Oleksiy



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

Re: [OSM-talk] Max speed forward/backward

[Shaun McDonald]

Hi Hans,

Do you have an example that you have mapped?

Shaun
> On 5 Jul 2016, at 22:09, Hans De Kryger  wrote:
> 
> Thanks Paul.
> 
> There's a lot of split speed limits here in the valley (Arizona.) I've worked 
> hard mapping quite a few. Would love for more services to show them.
> 
> 
> On Jul 5, 2016 2:41 AM, "Paul Johnson"  > wrote:
> On Sun, Jul 3, 2016 at 6:10 PM, Hans De Kryger  > wrote:
> 
> 
> ​Anyone know of any apps or services that display​ max speed forward/backward 
> tags. I assume most don't know how to?
> 
> I know that Osmand will as I've seen it come up on some odd edge cases where 
> sign placement is weird (normally Oklahoma doesn't do these split limits 
> unless it's not feasible to signpost the limits in the same spot both 
> directions).  Someone up towards Colorado should have more exact information, 
> as split limits are routine in that state.
> 
> ___
> talk mailing list
> talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk 
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [Talk-it] Ubuntu Touch e OpenStreetMap

[Andrea Albani]

>
> scusami, mi sono confuso...credevo che fosse la policy di openlayers...su
> openlayers non ho trovato nulla al riguardo...che è appunto quello di cui
> mi
> lamentavo/chiedevo: appoggiandosi allo stesso servizio (tile di osm) non
> dovrebbero come minimo imporre la stessa policy per il loro utilizzo...
> quanto meno linkare ai link da te postati?
>
>
Openlayers, leaflet, etc sono semplicemente librerie. Perchè dovrebbero
imporre delle policy d'uso relativamente ai tile server con cui si possono
potenzialmente interfacciare ?

E' chi adotta Openlayers in un proprio progetto che ha l'onere di  essere
compliant rispetto alle policy dei servizi terzi che usa.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] Špatná velikost písmen v názvech ulic importovaných z UIR-ADR

[Lukáš Karas]

Dne středa 6. července 2016 10:00:36 CEST Marián Kyral napsal(a):
> Dne 6.7.2016 v 09:41 Lukáš Karas napsal(a):
> > Ahoj, možná se toto téma již v listu řešilo, ale žádné vlákno jsem
> > nenašel.
> > Případně mě omluvte.
> > 
> > Píšu aplikaci nad knihovnou OSM Scout, při importu Česka jsem si všiml že
> > ve výsledné databázi chybí mnoho adres. Po dalším zkoumání jsem zjistil
> > že hodnota "addr:street" neodpovídá žádné blízké ulici (knihovna se snaží
> > z adres vytvořit stromovou strukturu, pokud nenajde odkazovanou ulici,
> > náměstí nebo sídliště..., adresu nepřidá do databáze). Po dalším zkoumání
> > jsem zjistil že mnoho adresních bodů má špatnou velikost písmen v tagu
> > "addr:street", například v ulici "V Olšinách" je mnoho (96) adres které
> > mají ulici uvedenou jako "V olšinách".
> > 
> > Hledání ulic jsem v knihovně udělal chytřejší, aby ignorovalo velikost
> > písmen. Nevím ale jestli její autor přijme merge request. V každém
> > případě si myslím že data v OSM by měla být opravena. Ale není to na
> > ruční práci, jen v Praze jsem našel 10 tisíc záznamů. Je tu někdo by byl
> > schopný napsat automatický script? Mohu dodat log z importu kde jsou
> > chyby vypsány...
> > 
> > Lukáš
> > 
> > 
> > ___
> > Talk-cz mailing list
> > Talk-cz@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz
> 
> A jak je to v RUIANu? Stejně? Tak to by pak bylo potřeba opravit tam.
> Což znamená nahlásit na ČÚZK, ti to přepošlou daným úředníkům a ti s tím
> možná něco udělají. A pak se to při update dostane až do OSM.
> 
> Ale pokud je to v RUIANu správně, tak by se to mělo v OSM opravit. Možná
> by stačilo, kdyby to Petr Vejsada zakomponoval do update skriptu. Ale
> nevím jak je na tom teď s časem, nějakou dobu se tu už neukázal.
> 
> 
> Jinak mi připadá ignorování velikosti písma při hledání jako docela
> dobrá vlastnost, která by měla být implementována. Stejně tak i nějaká
> odolnost proti překlepům. To sice nevím jak se dělá, ale určitě by bylo
> fajn, kdyby mi při hledání ulice "Na Olinách" byla nabídnuta i ulice "Na
> Olšinách".
> 
> Marián

Jo, v katastru je to stejně tak blbě. Například:

Stavební objekt:č. p. 2515, č. p. 2516, č. p. 2517, č. p. 2539
Ulice:  Buková, Osiková, Pod lipami

lipami by mělo být s velkým písmenem, v OSM je ulice správně "Pod Lipami".

Koukám že RUIAN obsahuje formulář pro zasílání oprav [1]. Obsahuje tam ale 
vtipnou poznámku: "Návrhy na změny velikosti písmen budou zamítnuty 
automaticky."

Co to sakra je?

Pokud existuje script kterým se provádí automatický import periodicky, 
mohl bych se pokusit jej rozšířit o opravu známých chyb... Najdu jej někde 
veřejně, třeba na githubu?

Lukáš

1) 
http://reklamace.cuzk.cz/formular/index.php?source=R%C3%9AIAN=ul-dnu=Zm%C4%9Bna+n%C3%A1zvu+existuj%C3%ADc%C3%AD
+ulice=-3=form

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

Re: [Talk-it] Ubuntu Touch e OpenStreetMap

[emmexx]

On 07/06/2016 10:01 AM, Aury88 wrote:
> scusami, mi sono confuso...credevo che fosse la policy di openlayers...su
> openlayers non ho trovato nulla al riguardo...che è appunto quello di cui mi
> lamentavo/chiedevo: appoggiandosi allo stesso servizio (tile di osm) non
> dovrebbero come minimo imporre la stessa policy per il loro utilizzo...
> quanto meno linkare ai link da te postati?

Openlayers e' solamente un client che fornisce delle api per connettersi
a vari provider di mappe.
Sta a chi utilizza queste librerie (OL, leaflet, ecc.) verificare i
termini di utilizzo dei provider.

ciao
maxx

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

Re: [Talk-it] WTOSM

[Simone Cortesi]

2016-07-04 19:31 GMT+02:00 Simone F. :
> Il giorno 4 luglio 2016 19:09, Simone Cortesi  ha
> scritto:
>>
>> Ricordo male o Cristian Consonni aveva realizzato qualcosa che poteva
>> facilitare questa operazione?
>
> Mi sa di no.
> Se non sbaglio, le sue modifiche [0] aggiungono automaticamente il template
> Coord a Wikipedia, senza passare per gli appunti dell'utente.

Grazie,
altra cosa secondo me interessante sarebbe aggiungere anche la chiave wikidata.

-- 
-S

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

Re: [Talk-it] guida per principianti

[Luca-SP]

la guida msmountain è molto discorsiva con vari casi pratici ed esempi di
errori comuni, tuttavia visto che si parla di escursionismo devo segnalare
che non chiarisce bene la differenza (importantissima) tra way e relation,
addirittura suggerisce di mettere il tag ref alla way (sbagliato per quanto
ne so).



--
View this message in context: 
http://gis.19327.n5.nabble.com/guida-per-principianti-tp5877214p5877409.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[Philippe Verdy]

Et même chose avec les nouvelles routes métropolitaines: mais pas de code
évident (les métropoles ont juste des codes SIREN, pas très pratiques, peu
nombreuses, autant les nommer avec un préfixe "FR:",
"network=FR:Nom-de-la-ville:m-road", pas besoin de donner le nom complet de
la métropole, par exemple "network=FR:Nice:m-road"

Les routes de la métropole de Lyon (qui n'est plus un département)
ont-elles changé de code? Sinon c'est toujours "network=FR-69:d-road", en
attendant "network=FR:Lyon:m-road" quand elles seront renumérotées une fois
les transferts de l'ancien département terminés (en attendant elles sont
cogérées par le nouveau département et la métropole)

Le tag operator est plus compliqué : si une commune peut en avoir la charge
pour le compte d'un département, elle ne gérera que certaines sections de
la départementale sur son propre territoire ou sur la frontière. Pour la
relation de la départementale je me passerais totalement de mentionner un
"operator" (situation différente en revanche pour les réseaux de bus qui
ont nécessairement un opérateur pour employer les chauffeurs, vendre les
billets, assurer les véhicules et passagers)...

Sinon je ne pense pas q'uil soit pertient d'ajouter les réseaux routiers
(ou autres itinéraires) en tant que membre d'une relation frontière
(d'autant que ces réseaux débordent souvent sur les départements ou régions
voisines). Les relations frontières en fait ne codent pas les collectivités
elles-mêmes mais leurs territoires de compétence concernant les résidents,
et de droits de collecte fiscale ou droit de réglementer, ou bien les
limites de compétence préfectorale (concernant les services déconcentrés de
l'Etat).

Le 6 juillet 2016 à 09:56, Francescu GAROBY  a écrit :

> Beau travail auquel tu t'attaques !
> J'ai moi-même commencé à faire la même chose avec les RT (routes
> territoriales) de Corse (anciennes RN). Je vais donc suivre attentivement
> cette discussion !
>
> Et sinon, je déconseille l'usage du tag "is_in", qui n'a plus de sens
> maintenant que les recherches géographiques sont possibles.
>
>
> Francescu
>
> Le 6 juillet 2016 à 09:15, Topographe Fou  a
> écrit :
>
>> Bonjour,
>>
>> Merci pour ce premier retour.
>>
>> Pour le 1.2 en effet je voulais parler des codes INSEE du département et
>> de celui de la région. Je partage également le point de vue que cela ne
>> contient pas plus d'informations dans le cas des RD. Mais si on se place
>> dans une logique d'arborescence alors il pourrait être pratique de faire
>> des recherches ou filtres par région. Hiérarchiquement parlant entre le
>> pays et le département il y a une région :). Il y a une solution
>> peut-être la plus logique (voir après).
>>
>> Proposition 1.4 : network=FR:78 (cad c'est une route départementale des
>> Yvelines en France) + is_in=FR:11:78 (cad c'est une relation dans le
>> département des Yvelines, région IDF, en France). Is_in est pas mal utilisé
>> aux EU, pour un statut assez vague.
>>
>> Proposition 1.5 : mettre les relations RD membre de la relation
>> Département pour créer explicitement la hiérarchie + network=FR:78
>>
>> Ok pour l'avis sur le 2.
>>
>> Pour le 'operator' je le préciserai sur le Wiki au moment de faire la
>> synthèse.  En ce qui me concerne cela sort de mon périmètre.
>>
>> LeTopographeFou
>> *De:*fl.infosrese...@gmail.com
>> *Envoyé:*6 juillet 2016 8:05 AM
>> *À:*talk-fr@openstreetmap.org
>> *Répondre à:*talk-fr@openstreetmap.org
>> *Objet:*Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de
>> type route départementale
>>
>> Hello,
>>
>> Bonne initiative, ça va en effet permettre de significativement améliorer
>> la qualité des données de routage, avec un bon impact sur les rendus
>> routiers
>>
>> Deux remarques pour amener de l'eau a ton moulin :
>> Point 1.2 : tu devais vouloir parler de l'INSEE région ? Inutile selon
>> moi, c'est bien un réseau départemental. Si on veut l'INSEE région, on le
>> trouve via l'INSEE du département
>> Point 2.3 : En effet, il ne faut pas refonder inutilement l'info et cette
>> solution de passer par network=* est la meilleure sur ce plan.
>>
>> Autre chose : il faudrait utiliser operator=* pour indiquer l'exploitant,
>> idéalement sur chaque segment de route, puisque l'exploitation des tronçons
>> urbain peut être délégué aux villes.
>>
>> A+
>>
>> François
>> Le 6 juil. 2016 12:25 AM, "LeTopographeFou" 
>> a écrit :
>>
>> Bonjour,
>>
>> J'ai attaqué un imposant chantier visant à améliorer la prise en compte
>> des Routes Départementales (RD) françaises dans OSM. Ce chantier vise à :
>>
>>1. Faire qu'il y ait une relation par RD par département (ex :
>>http://www.openstreetmap.org/relation/6335278)
>>2. Vérifier et corrigé le tracé des RD
>>
>> Le tout étant fait *à la main* (j'insiste sur le fait qu'il n'y a pas
>> d'automate) en comparant les données OSM avec Route500. A ce jour j'ai fais
>> les Yvelines et attaque 

Re: [Talk-it] Ubuntu Touch e OpenStreetMap

[Aury88]

Aury88 wrote
> "OpenStreetMap is a volunteer-run non-profit body and cannot supply
> tiles for large-scale commercial use."
> 
> [ https://switch2osm.org/using-tiles/ ]

scusami, mi sono confuso...credevo che fosse la policy di openlayers...su
openlayers non ho trovato nulla al riguardo...che è appunto quello di cui mi
lamentavo/chiedevo: appoggiandosi allo stesso servizio (tile di osm) non
dovrebbero come minimo imporre la stessa policy per il loro utilizzo...
quanto meno linkare ai link da te postati?




-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/Ubuntu-Touch-e-OpenStreetMap-tp5834454p5877407.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-cz] Špatná velikost písmen v názvech ulic importovaných z UIR-ADR

[Marián Kyral]

Dne 6.7.2016 v 09:41 Lukáš Karas napsal(a):
> Ahoj, možná se toto téma již v listu řešilo, ale žádné vlákno jsem nenašel. 
> Případně mě omluvte.
>
> Píšu aplikaci nad knihovnou OSM Scout, při importu Česka jsem si všiml že ve 
> výsledné databázi chybí mnoho adres. Po dalším zkoumání jsem zjistil že 
> hodnota "addr:street" neodpovídá žádné blízké ulici (knihovna se snaží z 
> adres 
> vytvořit stromovou strukturu, pokud nenajde odkazovanou ulici, náměstí nebo 
> sídliště..., adresu nepřidá do databáze). Po dalším zkoumání jsem zjistil že 
> mnoho adresních bodů má špatnou velikost písmen v tagu "addr:street", 
> například v ulici "V Olšinách" je mnoho (96) adres které mají ulici uvedenou 
> jako "V olšinách". 
>
> Hledání ulic jsem v knihovně udělal chytřejší, aby ignorovalo velikost 
> písmen. 
> Nevím ale jestli její autor přijme merge request. V každém případě si myslím 
> že data v OSM by měla být opravena. Ale není to na ruční práci, jen v Praze 
> jsem našel 10 tisíc záznamů. Je tu někdo by byl schopný napsat automatický 
> script? Mohu dodat log z importu kde jsou chyby vypsány...
>
> Lukáš
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

A jak je to v RUIANu? Stejně? Tak to by pak bylo potřeba opravit tam.
Což znamená nahlásit na ČÚZK, ti to přepošlou daným úředníkům a ti s tím
možná něco udělají. A pak se to při update dostane až do OSM.

Ale pokud je to v RUIANu správně, tak by se to mělo v OSM opravit. Možná
by stačilo, kdyby to Petr Vejsada zakomponoval do update skriptu. Ale
nevím jak je na tom teď s časem, nějakou dobu se tu už neukázal.


Jinak mi připadá ignorování velikosti písma při hledání jako docela
dobrá vlastnost, která by měla být implementována. Stejně tak i nějaká
odolnost proti překlepům. To sice nevím jak se dělá, ale určitě by bylo
fajn, kdyby mi při hledání ulice "Na Olinách" byla nabídnuta i ulice "Na
Olšinách".

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

Re: [Talk-it] Ubuntu Touch e OpenStreetMap

[Andrea Albani]

> Per questo tipo di servizi penso sia meglio mettere in piedi qualcosa su
> aws o simile.
> Su aws si puo' installare un server virtuale gratuito per il primo anno.
> Il servizio ha caratteristiche base ma e' inutile mettere in piedi un
> elefante senza sapere quale sara' l'uso effettivo.
> Su questo server si puo' mettere in piedi un tile server o geoserver per
> fornire i tile con i dati osm. Sul wiki si trovano info in vari documenti.
>
>
Corretto, ma per un massimo di circa 31 giorni di accensione continua... e
comunque per una macchina poco adeguata all'uso (monoprocessore con 1 GB di
RAM e 30 GB di disco)... senza contare il limite di 15GB sui dati in uscita
verso Internet.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Ubuntu Touch e OpenStreetMap

[Aury88]

emmexx wrote
> On 07/06/2016 09:17 AM, Aury88 wrote:
>> quindi se ho capito bene di fatto usando quei servizi si occupa comunque
>> la
>> banda dei server OSM...
>> è strano comunque che venga permesso...stando al wiki di OSM per accedere
>> al
>> servizio "interno" tile di OSM bisogna fare formale richiesta che deve
>> venir
>> valutata in funzione del traffico...come mai usando leaflet o openlayer
>> lo
>> stesso servizio tile di osm viene fornito senza remore?
> 
> "OpenStreetMap is a volunteer-run non-profit body and cannot supply
> tiles for large-scale commercial use."
> 
> [ https://switch2osm.org/using-tiles/ ]
> 
> "Heavy use (e.g. distributing an app that uses tiles from
> openstreetmap.org) is forbidden without prior permission from the System
> Administrators."
> 
> [ http://wiki.openstreetmap.org/wiki/Tile_usage_policy ]

Cavoli...non l'avevo notato o_o...sorry.

> Ritengo che per usi limitati non ci siano problemi.

temo non sia questo il caso...i tile service che usava prima sono stati
abbandonati perchè l'app ha cominciato a generare una quantità di traffico
sufficientemente elevato da comportare l'applicazione di un costo...per
quanto sicuramente sopportabile dai server OSM non sarebbe comunque corretto
caricare questo traffico sulla loro infrastruttura... e il primo a dire
questo  è lo stesso sviluppatore dell'app in questione. vediamo!...troveremo
sicuramente una soluzione ;-)

grazie ragazzi per i chiarimenti :-)



-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/Ubuntu-Touch-e-OpenStreetMap-tp5834454p5877404.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[Francescu GAROBY]

Beau travail auquel tu t'attaques !
J'ai moi-même commencé à faire la même chose avec les RT (routes
territoriales) de Corse (anciennes RN). Je vais donc suivre attentivement
cette discussion !

Et sinon, je déconseille l'usage du tag "is_in", qui n'a plus de sens
maintenant que les recherches géographiques sont possibles.


Francescu

Le 6 juillet 2016 à 09:15, Topographe Fou  a
écrit :

> Bonjour,
>
> Merci pour ce premier retour.
>
> Pour le 1.2 en effet je voulais parler des codes INSEE du département et
> de celui de la région. Je partage également le point de vue que cela ne
> contient pas plus d'informations dans le cas des RD. Mais si on se place
> dans une logique d'arborescence alors il pourrait être pratique de faire
> des recherches ou filtres par région. Hiérarchiquement parlant entre le
> pays et le département il y a une région :). Il y a une solution
> peut-être la plus logique (voir après).
>
> Proposition 1.4 : network=FR:78 (cad c'est une route départementale des
> Yvelines en France) + is_in=FR:11:78 (cad c'est une relation dans le
> département des Yvelines, région IDF, en France). Is_in est pas mal utilisé
> aux EU, pour un statut assez vague.
>
> Proposition 1.5 : mettre les relations RD membre de la relation
> Département pour créer explicitement la hiérarchie + network=FR:78
>
> Ok pour l'avis sur le 2.
>
> Pour le 'operator' je le préciserai sur le Wiki au moment de faire la
> synthèse.  En ce qui me concerne cela sort de mon périmètre.
>
> LeTopographeFou
> *De:*fl.infosrese...@gmail.com
> *Envoyé:*6 juillet 2016 8:05 AM
> *À:*talk-fr@openstreetmap.org
> *Répondre à:*talk-fr@openstreetmap.org
> *Objet:*Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de
> type route départementale
>
> Hello,
>
> Bonne initiative, ça va en effet permettre de significativement améliorer
> la qualité des données de routage, avec un bon impact sur les rendus
> routiers
>
> Deux remarques pour amener de l'eau a ton moulin :
> Point 1.2 : tu devais vouloir parler de l'INSEE région ? Inutile selon
> moi, c'est bien un réseau départemental. Si on veut l'INSEE région, on le
> trouve via l'INSEE du département
> Point 2.3 : En effet, il ne faut pas refonder inutilement l'info et cette
> solution de passer par network=* est la meilleure sur ce plan.
>
> Autre chose : il faudrait utiliser operator=* pour indiquer l'exploitant,
> idéalement sur chaque segment de route, puisque l'exploitation des tronçons
> urbain peut être délégué aux villes.
>
> A+
>
> François
> Le 6 juil. 2016 12:25 AM, "LeTopographeFou"  a
> écrit :
>
> Bonjour,
>
> J'ai attaqué un imposant chantier visant à améliorer la prise en compte
> des Routes Départementales (RD) françaises dans OSM. Ce chantier vise à :
>
>1. Faire qu'il y ait une relation par RD par département (ex :
>http://www.openstreetmap.org/relation/6335278)
>2. Vérifier et corrigé le tracé des RD
>
> Le tout étant fait *à la main* (j'insiste sur le fait qu'il n'y a pas
> d'automate) en comparant les données OSM avec Route500. A ce jour j'ai fais
> les Yvelines et attaque l'Essonne. Aucune des RD n'avait de relation ad-hoc
> et certaines n'étaient carrément pas (ou incomplètement) référencées par
> leurs champ ref=*. Donc je les attaque une à une avec de belles trouvailles.
>
> Pour le moment je mets 4 tags à chaque relations (cf.
> http://www.openstreetmap.org/relation/6335278) mais je ne trouve pas cela
> très optimal d'où deux points à vous soumettre :
>
>1. Il faudrait en profiter pour mettre un tag 'network'. Pour info les
>RN ont visiblement un tag 'network=FR:n-road'. Afin de coller avec la
>logique utilisées aux EU j'ai deux propositions à faire :
>2.
>   1. Utiliser le code pays et le code INSEE du département (en
>   l’occurrence cela ferait 'FR:78')
>   2. Faire comme précédemment mais avec également le code INSEE du
>   département (en l’occurrence cela ferait 'FR:11:78)
>   3. Utiliser le code ISO 3166-2 (en l’occurrence cela ferait 'FR-78')
>3. Concernant le tag 'name' il y a des risques d'amalgames entre deux
>départements. Est-il judicieux d'y mentionner le nom du département ? Le
>hic est que, rigoureusement parlant, le nom "officiel" est 'Route
>départementale 29' sans autre fioriture
>4.
>   1. Exemple 1 : 'Route départementale 29 (Yvelines)' => clair et
>   concis, facile à parser
>   2. Exemple 2 : 'Route départementale des Yvelines 29' => bof
>   3. Autre solution : ne rien faire, se dire que l'ajout de 'network'
>   suffit et que si amalgame il y a c'est un problème à gérer par
>   l'éditeur/l'app et non par le cartographe => c'est ma solution préféré 
> mais
>   autant réfléchir avant d'aller plus loin.
>
> A ce jour je ne vois pas de réponse ni dans les relations existantes ni
> sur le wiki. Qu'en pensez-vous ?
>
> LeTopographeFou
>
> ___
> 

Re: [Talk-it] Ubuntu Touch e OpenStreetMap

[emmexx]

On 07/06/2016 09:17 AM, Aury88 wrote:
> quindi se ho capito bene di fatto usando quei servizi si occupa comunque la
> banda dei server OSM...
> è strano comunque che venga permesso...stando al wiki di OSM per accedere al
> servizio "interno" tile di OSM bisogna fare formale richiesta che deve venir
> valutata in funzione del traffico...come mai usando leaflet o openlayer lo
> stesso servizio tile di osm viene fornito senza remore?

"OpenStreetMap is a volunteer-run non-profit body and cannot supply
tiles for large-scale commercial use."

[ https://switch2osm.org/using-tiles/ ]

"Heavy use (e.g. distributing an app that uses tiles from
openstreetmap.org) is forbidden without prior permission from the System
Administrators."

[ http://wiki.openstreetmap.org/wiki/Tile_usage_policy ]

Ritengo che per usi limitati non ci siano problemi.

> 
> Marcos sta provando a mettere in piedi un sistema di mappe offline e
> realizzare un proprio tile server, ma ha risorse limitate e il suo computer
> home server (un vecchio computer connesso alla rete) non è abbastanza
> potente ed è da settimane che sta generando il render...e comunque non credo
> che la banda che ha a casa sia in grado di gestire un traffico dati così
> elevato :-/

Per questo tipo di servizi penso sia meglio mettere in piedi qualcosa su
aws o simile.
Su aws si puo' installare un server virtuale gratuito per il primo anno.
Il servizio ha caratteristiche base ma e' inutile mettere in piedi un
elefante senza sapere quale sara' l'uso effettivo.
Su questo server si puo' mettere in piedi un tile server o geoserver per
fornire i tile con i dati osm. Sul wiki si trovano info in vari documenti.

ciao
maxx


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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[Philippe Verdy]

A mon avis le code ISO 3166-2 est le plus simple à interpréter dans le code
du réseau avec un seul préfixe: "network=FR-68:d-road"...
Pour le nom, l'exemple 1 "name=Route départementale 29 (Yvelines)" est
assez clair.

Le 6 juillet 2016 à 00:28, LeTopographeFou  a
écrit :

> Bonjour,
>
> J'ai attaqué un imposant chantier visant à améliorer la prise en compte
> des Routes Départementales (RD) françaises dans OSM. Ce chantier vise à :
>
>1. Faire qu'il y ait une relation par RD par département (ex :
>http://www.openstreetmap.org/relation/6335278)
>2. Vérifier et corrigé le tracé des RD
>
> Le tout étant fait *à la main* (j'insiste sur le fait qu'il n'y a pas
> d'automate) en comparant les données OSM avec Route500. A ce jour j'ai fais
> les Yvelines et attaque l'Essonne. Aucune des RD n'avait de relation ad-hoc
> et certaines n'étaient carrément pas (ou incomplètement) référencées par
> leurs champ ref=*. Donc je les attaque une à une avec de belles trouvailles.
>
> Pour le moment je mets 4 tags à chaque relations (cf.
> http://www.openstreetmap.org/relation/6335278) mais je ne trouve pas cela
> très optimal d'où deux points à vous soumettre :
>
>1. Il faudrait en profiter pour mettre un tag 'network'. Pour info les
>RN ont visiblement un tag 'network=FR:n-road'. Afin de coller avec la
>logique utilisées aux EU j'ai deux propositions à faire :
>   1. Utiliser le code pays et le code INSEE du département (en
>   l’occurrence cela ferait 'FR:78')
>   2. Faire comme précédemment mais avec également le code INSEE du
>   département (en l’occurrence cela ferait 'FR:11:78)
>   3. Utiliser le code ISO 3166-2 (en l’occurrence cela ferait 'FR-78')
>2. Concernant le tag 'name' il y a des risques d'amalgames entre deux
>départements. Est-il judicieux d'y mentionner le nom du département ? Le
>hic est que, rigoureusement parlant, le nom "officiel" est 'Route
>départementale 29' sans autre fioriture
>1. Exemple 1 : 'Route départementale 29 (Yvelines)' => clair et
>   concis, facile à parser
>   2. Exemple 2 : 'Route départementale des Yvelines 29' => bof
>   3. Autre solution : ne rien faire, se dire que l'ajout de 'network'
>   suffit et que si amalgame il y a c'est un problème à gérer par
>   l'éditeur/l'app et non par le cartographe => c'est ma solution préféré 
> mais
>   autant réfléchir avant d'aller plus loin.
>
> A ce jour je ne vois pas de réponse ni dans les relations existantes ni
> sur le wiki. Qu'en pensez-vous ?
>
> LeTopographeFou
>
> ___
> 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-cz] Špatná velikost písmen v názvech ulic importovaných z UIR-ADR

[Lukáš Karas]

Ahoj, možná se toto téma již v listu řešilo, ale žádné vlákno jsem nenašel. 
Případně mě omluvte.

Píšu aplikaci nad knihovnou OSM Scout, při importu Česka jsem si všiml že ve 
výsledné databázi chybí mnoho adres. Po dalším zkoumání jsem zjistil že 
hodnota "addr:street" neodpovídá žádné blízké ulici (knihovna se snaží z adres 
vytvořit stromovou strukturu, pokud nenajde odkazovanou ulici, náměstí nebo 
sídliště..., adresu nepřidá do databáze). Po dalším zkoumání jsem zjistil že 
mnoho adresních bodů má špatnou velikost písmen v tagu "addr:street", 
například v ulici "V Olšinách" je mnoho (96) adres které mají ulici uvedenou 
jako "V olšinách". 

Hledání ulic jsem v knihovně udělal chytřejší, aby ignorovalo velikost písmen. 
Nevím ale jestli její autor přijme merge request. V každém případě si myslím 
že data v OSM by měla být opravena. Ale není to na ruční práci, jen v Praze 
jsem našel 10 tisíc záznamů. Je tu někdo by byl schopný napsat automatický 
script? Mohu dodat log z importu kde jsou chyby vypsány...

Lukáš


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

[Talk-GB] OSM UK local chapter

[Brian Prangle]

Hi everyone

We have now secured a pro bono lawyer to review the AoA (courtesy of
Birmingham Science Park).

I've started to fill in in the documentation required by Companies House.
For those of you who have volunteerd to be initial directors I need the
following from each of you:

Title
Full Forenames
Surname
Former name(s)   if used for business purposes in the last 20 years
Country/State of Residence
Nationality
Usual Residential Address
Month/Year of birth
Business Occupation
Are you in the process of applying for or have been granted exemption by
the Registrar from disclosing your usual residential address to credit
reference agencies under section 243 of the Companies Act 2006?

Regards

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

Re: [OSM-talk-be] municipal boundaries in Belgium

[joost schouppe]

>
> What is the authority for this? Who is the boss about where a municipality
> ends? Can it be copied from there? Intuitively I'd think those official
> borders should not be able to be copyrighted.
>

The data for Flanders is available [1] through Agiv, I mean The
Organisation Formerly Known as AGIV. It comes with the Gratis Open Data
Licentie, which we decided is safe to use.

I would think the real authority is found in paper archives in municipal
basements. One day the community boundaries will stop being "voorlopig" in
the file offered by TOFKAGIV, and then that file will probably become the
only and official truth. For now, a big cleanup looks unnecesary, but where
small errors on our side cause problems, we can use the Agiv dataset as a
reference for fixes.

1:
https://www.agiv.be/news/2016/februari/update-voorlopig-referentiebestand-gemeentegrenzen
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-it] Ubuntu Touch e OpenStreetMap

[Alessandro Palmas]

Il 06/07/2016 09:17, Aury88 ha scritto:



quindi se ho capito bene di fatto usando quei servizi si occupa comunque la
banda dei server OSM...
è strano comunque che venga permesso...stando al wiki di OSM per accedere al
servizio "interno" tile di OSM bisogna fare formale richiesta che deve venir
valutata in funzione del traffico...come mai usando leaflet o openlayer lo
stesso servizio tile di osm viene fornito senza remore?



Tu utilizzi OpenLayers e LeafLet come uno strumento, esattamente come 
milioni di persone usano Firefox per accedere alle tiles tramite 
www.openstreetmap.org , ma l'utilizzo è distribuito su una miriade di IP 
diversi. La Foundation ha server e banda sufficiente per erogare questo 
servizio base.
Il problema si pone quando una singola App o un singolo IP address 
generano un sacco di traffico; a quel punto gli si chiede di provvedere 
in altro modo.


Alessandro Ale_Zena_IT

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

Re: [Talk-it] Ubuntu Touch e OpenStreetMap

[Aury88]

Alessandro Palmas wrote
> Il problema è sempre quello: la banda e il server che deve gestire le 
> richieste; in quel modo è tutto a carico dei soliti server.
> La prima soluzione sarebbe avere mappe offline, uno si scarica la zone 
> che frequenta di più così minimizza il carico sui server e il consumo 
> del suo traffico internet. A quel punto potrebbe provare ad ottenere un 
> server e un pò di banda da qualche università (o magari da due così 
> bilancia un pò il traffico).
> 
> Alessandro Ale_Zena_IT

quindi se ho capito bene di fatto usando quei servizi si occupa comunque la
banda dei server OSM...
è strano comunque che venga permesso...stando al wiki di OSM per accedere al
servizio "interno" tile di OSM bisogna fare formale richiesta che deve venir
valutata in funzione del traffico...come mai usando leaflet o openlayer lo
stesso servizio tile di osm viene fornito senza remore?

Marcos sta provando a mettere in piedi un sistema di mappe offline e
realizzare un proprio tile server, ma ha risorse limitate e il suo computer
home server (un vecchio computer connesso alla rete) non è abbastanza
potente ed è da settimane che sta generando il render...e comunque non credo
che la banda che ha a casa sia in grado di gestire un traffico dati così
elevato :-/



-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/Ubuntu-Touch-e-OpenStreetMap-tp5834454p5877399.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[Topographe Fou]

 Bonjour,Merci pour ce premier retour.Pour le 1.2 en effet je voulais parler des codes INSEE du département et de celui de la région. Je partage également le point de vue que cela ne contient pas plus d'informations dans le cas des RD. Mais si on se place dans une logique d'arborescence alors il pourrait être pratique de faire des recherches ou filtres par région. Hiérarchiquement parlant entre le pays et le département il y a une région :). Il y a une solution peut-être la plus logique (voir après).Proposition 1.4 : network=FR:78 (cad c'est une route départementale des Yvelines en France) + is_in=FR:11:78 (cad c'est une relation dans le département des Yvelines, région IDF, en France). Is_in est pas mal utilisé aux EU, pour un statut assez vague.Proposition 1.5 : mettre les relations RD membre de la relation Département pour créer explicitement la hiérarchie + network=FR:78Ok pour l'avis sur le 2.Pour le 'operator' je le préciserai sur le Wiki au moment de faire la synthèse.  En ce qui me concerne cela sort de mon périmètre. LeTopographeFou  De:fl.infosrese...@gmail.comEnvoyé:6 juillet 2016 8:05 AMÀ:talk-fr@openstreetmap.orgRépondre à:talk-fr@openstreetmap.orgObjet:Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale  Hello,
Bonne initiative, ça va en effet permettre de significativement améliorer la qualité des données de routage, avec un bon impact sur les rendus routiers
Deux remarques pour amener de l'eau a ton moulin :
Point 1.2 : tu devais vouloir parler de l'INSEE région ? Inutile selon moi, c'est bien un réseau départemental. Si on veut l'INSEE région, on le trouve via l'INSEE du département 
Point 2.3 : En effet, il ne faut pas refonder inutilement l'info et cette solution de passer par network=* est la meilleure sur ce plan.
Autre chose : il faudrait utiliser operator=* pour indiquer l'exploitant, idéalement sur chaque segment de route, puisque l'exploitation des tronçons urbain peut être délégué aux villes.
A+
François
Le 6 juil. 2016 12:25 AM, "LeTopographeFou"  a écrit :
  


  
  
Bonjour,

J'ai attaqué un imposant chantier visant à améliorer la prise en
compte des Routes Départementales (RD) françaises dans OSM. Ce
chantier vise à :
Faire qu'il y ait une relation par RD par département (ex :
http://www.openstreetmap.org/relation/6335278)
  Vérifier et corrigé le tracé des RD
Le tout étant fait à la main (j'insiste sur le fait qu'il
  n'y a pas d'automate) en comparant les données OSM avec Route500.
  A ce jour j'ai fais les Yvelines et attaque l'Essonne. Aucune des
  RD n'avait de relation ad-hoc et certaines n'étaient carrément pas
  (ou incomplètement) référencées par leurs champ ref=*. Donc je les
  attaque une à une avec de belles trouvailles.

Pour le moment je mets 4 tags à chaque relations (cf.
  http://www.openstreetmap.org/relation/6335278) mais je ne trouve
  pas cela très optimal d'où deux points à vous soumettre :

Il faudrait en profiter pour mettre un tag 'network'. Pour
info les RN ont visiblement un tag 'network=FR:n-road'. Afin de
coller avec la logique utilisées aux EU j'ai deux propositions à
faire :Utiliser le code pays et le code INSEE du département (en
  l’occurrence cela ferait 'FR:78')Faire comme précédemment mais avec également le code INSEE
  du département (en l’occurrence cela ferait 'FR:11:78)
Utiliser le code ISO 3166-2 (en l’occurrence cela ferait
  'FR-78')
  Concernant le tag 'name' il y a des risques d'amalgames entre
deux départements. Est-il judicieux d'y mentionner le nom du
département ? Le hic est que, rigoureusement parlant, le nom
"officiel" est 'Route départementale 29' sans autre fioriture
  Exemple 1 : 'Route départementale 29 (Yvelines)' => clair
  et concis, facile à parser
Exemple 2 : 'Route départementale des Yvelines 29' => bofAutre solution : ne rien faire, se dire que l'ajout de
  'network' suffit et que si amalgame il y a c'est un problème à
  gérer par l'éditeur/l'app et non par le cartographe =>
  c'est ma solution préféré mais autant réfléchir avant d'aller
  plus loin.


A ce jour je ne vois pas de réponse ni dans les relations
  existantes ni sur le wiki. Qu'en pensez-vous ?

LeTopographeFou

  

___
Talk-fr mailing list
Talk-fr@openstreetmap.org

Re: [Talk-it] Ubuntu Touch e OpenStreetMap

[emmexx]

On 07/06/2016 09:03 AM, Alessandro Palmas wrote:
> 
> Scusa, ma LeafLet è leggero per erogare i propri servizi, per le tile si
> appoggia sempre a un WMS

Infatti ho scritto che non mi era ben chiara la richiesta. Se il
problema e' lo scaricamento dei tile, un client vale l'altro e il
problema resta.

ciao
maxx

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