Re: [OSM-talk-fr] recherche autorisation pour ortho Bordeaux et Languedoc-Roussillon

[marc marc]

Le 22. 02. 18 à 14:12, Vincent Bergeot a écrit :
> Le 22/02/2018 à 13:35, marc marc a écrit :
>> je continue la remise en ordre des couches eli/iD <> josm
>> Pour 2 couches, je ne trouve pas la mention de la licence permettant de
>> l'utiliser dans osm :
>> Bordeaux 2016 (ajout anonyme dans josm il y a 5 mois)
> 
> est ce que cela t'aide : https://data.bordeaux-metropole.fr/?new=117309
> et la licence : https://data.bordeaux-metropole.fr/license

oui cela conviendra :)

Le 22. 02. 18 à 14:21, Vincent Bergeot a écrit :
 >> Languedoc-Roussillon 2012
 > sans doute obsolète surtout ?
 > 
http://geocatalogue.siglr.org/geonetwork/srv/fr/metadata.show?uuid=4531ef8b-ae5e-4915-9af0-6419b737d47d
 

 > je ne suis pas sur de tout bien comprendre mais je dirais
 > que le 2016 est disponible ?

pareil, pas sur de tout comprendre, j'ai l'impression que ce sont
des jpeg2000 inutilisable en l'état pour osm.
Si quelqu'un trouve l'url 2016 qui va bien avec la licence,
je l'ajouterai.

Le 23. 02. 18 à 02:28, Thomas Gratier a écrit :
 > Le seul truc que je comprend pas est le rôle d'un ortho 2012 sur LR

elle peux être utile si une autre ortho a des nuages
ou si t'as besoin de revenir en arrière dans le temps pour comprendre 
une modif faite par exemple en 2013 dans osm.

 > quand on est sensé avoir accès aux ortho IGN pour contribuer

tu as accès
https://wiki.openstreetmap.org/wiki/FR:Sources_de_donn%C3%A9es_potentielles/France#IGN_BDOrtho

j'ai aussi une demande d'ajout dans les couches par défaut
de eli/iD/Vespucci
https://github.com/osmlab/editor-layer-index/pull/418

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

Re: [OSM-talk-be] Where to suggest/discuss the renderer?

[marc marc]

Le 23. 02. 18 à 07:44, Karel Adams a écrit :
> Whence my repeated question: where or with whom can this be discussed?

the tagging mailing for the schema
https://lists.openstreetmap.org/listinfo/tagging

github to use a current schema
https://github.com/gravitystorm/openstreetmap-carto/
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[Aury88]

non era mia intenzione scatenare tutto questo trambusto. 

Non metto in dubbio che ci siano persone che, nonostante quanto imponga OSM
e nonostante quanto vieti Google, utilizzi i dati google sistematicamente
per inserire elementi (siano essi note o dati) su OSM.

non ho neanche provato ad addentrarmi nella questione divieto lecito o il
fatto che sia provabile l'avvenuta trasgressione...

ho solo posto il quesito su una dichiarazione di un utente in cui
esplicitamente si affermava di utilizzare anche un servizio google per
inserire elementi (per ricordarseli? per scoprirne di nuovi?) su OSM

a fronte di una dichiarazione del genere anche il più incapace degli
avvocati è in grado di dimostrare la colpevolezza dell'utente visto che la
prova sarebbe l'affermazione dell'utente stesso (senza considerare che
google sa chi e quando si connette ad un proprio servizio e, nel caso di
streetview, quale area sta guardando...dati che presi assieme alla data,
utente e area del changelog  possono già essere una prova per alcuni
dell'avvenuta copiatura...ma questo è un altro discorso).

provato quindi o meglio ammesso che l'utente è andato contro le regole
google diventa lecito per google richiedere la rimozione dei dati inseriti
dall'utente (+ eventuali danni)...a quel punto cosa togliamo? difficilmente
il dato dell'utente è rimasto isolato...sarà stato modificato, unito,
diviso, usato come riferimento per altro anche da altri ecc ecc 



non succederà mai? non possiamo saperlo, ma sappiamo che non è impossibile e
questo basta per mettere a rischio non solo l'utente ma anche al progetto ed
al suo utilizzo da chi non vuole avere problemi dall'uso del db...

il mio parere? è comunque meglio evitare anche la sbirciatina...better safe
than sorry anche esagerando lato safe 

my 2 cents
aury




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

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

Re: [Talk-at] "geocodec/Socke/Johann Haag" stummschalten

[andreas wecer]

Wenn ich kompetenztechnisch inhaltlich noch etwas zur nicht
funktionierenden Suche anmerken darf: das eigentliche Problem sehe ich
darin, dass Nominatim öfter gar kein Ergebnis findet und es nicht schafft,
ein weniger spezifisches zu liefern, also bpsw. "Davidgasse 76-80" statt
"Davidgasse 76-80/14/10" - und eigenartigerweise funktioniert genau dieses
Beispiel jetzt bei Nominatim, während Volkis Nachbarn dagegen schon wieder
nicht mehr so viel Glück haben. Photon (die Such-Engine von komoot) wirkt
da bspw. nicht so erratisch.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [OSM-talk-be] Where to suggest/discuss the renderer?

[Karel Adams]

Glenn, hebt ge me wel goed gelezen?

There is not the slightest need to convince me we should not map for the 
renderer. There's a bunch of mappers, especially in France but also one 
in Italy, who vehemently remove the "aeroway=aerodrome" tag from small 
airfields. When I reinstate it, they will promptly remove it and send me 
angry messages.


I do not say they are right, I do say there is some reason to their 
approach. It is not acceptable that the renderer knows only one category 
of aerodrome so that it maps a small recreational aerodrome the same way 
as an international airport. This should be improved in the renderer, 
both to satisfy those Southern grumblers even if they're not right; but 
mainly to improve the map that we produce.


It is not because they are wrong in France that there is no room for 
improving the renderer. Whence my repeated question: where or with whom 
can this be discussed?


KA

PS one thing I have begun to do is to tag those small fields as 
"aeroway=airstrip" but that is not to everybody's liking, either.



On 22/02/18 09:41, Glenn Plas wrote:

Mapping for the renderer is de facto wrong and what you experience now
(in france etc.) is the endresult of that attitude.  I don't understand
why you get discouraged on OSM because of a map you don't like.   It's
like saying:  "I don't contribute to Wikipedia anymore because when I
print a page out, it's not aligned the way I want it."

There are several options for anyone in your situation:

1. make your own map.  There are several sites that allow you to make
custom maps.
2. more technical: copy cartoCSS, change whatever you want, set up a
tile server and enjoy your perfectly suited map
3. try to change the consensus, lobby for universal solution, try to get
the standard cartoCSS changed to your likings (and repeat later when
someone else does the same)
4. Look for existing map alternatives  (different renderings)

You should realise that it has nothing to do with the source data.
There are already ton's of different map rendering out there, perhaps
one will be perfect for you.

Don't stop mapping because of someone elses decision to represent a
feature in a way that doesn't appeal to you.  It's the worst reason to
stop as that might just change in an instant.

Glenn


On 19-01-18 16:43, Karel Adams wrote:

When I first consulted maps - paper-only, at that time, of course -
the famous Michelin 1:20 had distinct symbols for (bigger)
airports, (smaller) airfields, and glider fields. As of 2018, the
generic map of openstreetmap has only a single icon to represent
anything mapped with "aeroway:aerodrome" - and all of them rendered as
from zoomlevel=13 - and none below.

This is really very bad. Why should I want to contribute to a system
that delivers poorer info than paper maps of 50 years old?

Even worse, many active and able mappers are reluctant to update the
database properly because the correct info will be so poorly rendered.
Especially in France and Italy, where I had endless arguments with
people removing the "aeroway=aerodrome" tag from real proper
aerodromes, because they didn't want their local grass runway mapped
the same as CDG Roissy airport. Even if I don't agree, I can fully
understand their point of view!

What is the proper place to question this matter, and discuss schemes
of improvement? Is there a discussion site for the renderer?




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






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

Re: [OSM-talk] Mapping rivers that flow into/through lakes?

[Maarten Deen]

On 2018-02-22 22:59, Rory McCann wrote:

Hi mappers,

What's the best way to map rivers that flow into lakes, especially when
another river flows through it? Should they be connected?

When a river flows through a lake, you can map a waterway=river way
through it, to be "topoligcally complete". Or would it be better to add
ways (w/o waterway tag) to the river relation?

When a tributary river joins another, join the central waterway=river
ways together. But what if a river drains into a lake with a  "central
river" through it? Should you connect that river to the central river?
It makes topological sense.

If you asked someone "Where does this river end?" they'd probably point
to where it joins the lake. Connecting the river to the "central river"
breaks this. And it can result in odd long ways. I might have gone a
little OTT here (
http://tools.geofabrik.de/osmi/?view=water=27.98062=-16.95179=11
) or here (
http://tools.geofabrik.de/osmi/?view=water=-8.26705=52.99047=11
).


I see nothing wrong with those examples, I would do it the same, 
especially if the rivers can be sailed on by boat. Then you absolutely 
need the rivers to be connected to a central river (or fairway) in the 
lake.


Maarten

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

[OSM-talk] Is this legal to what philly.com is doing?

[James Mast]

http://www.philly.com/philly/news/politics/will-republicans-impeach-pennsylvania-supreme-court-justices-20180222.html


(ignore what the article is about)


Just happen to see a thumbnail and clicked on the article since I noticed the 
OSM base map.  Nowhere that I can find does it give credit to OSM for the use 
of it.


Now, the part to where I was curious if this was legal (sans the lack of 
credit), is that they are 'selling' the uploaded image.  Is that allowed 
currently under the license that OSM has?


Just thought I'd throw this out there for somebody more experienced in this 
sector.

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

Re: [OSM-talk-fr] Zones géographiques informelles

[Philippe Verdy]

Note qu'un noeud label n'a besoin d'aucun attribut (tag), ce n'est qu'une
suggestion de placement du libellé dans le cas où on ne voudrait pas le
placer au centre de la zone (multi-)polygonale. Les noms et propriétés
devraient toujours venir de ce polygone ou cette relation.

La seule chose qui sert c'est sa position géographique (ses coordonnées) et
en pratique cela ne sert que lorsque le centre de la zone n'est pas
adéquat, particulièrement dans les zone fortement concaves ou trouées, ou
ayant des enclaves externes pour pointer sur l'enclave principale et non
n'importe où en dehors hors de la zone, quand le moteur de rendu n'a pas
moyen de décider où placer le libellé correctement (il pourrait tenter de
déterminer la zone principale la plus grande, et éventuellement dupliquer
le libellé pour chacune des enclaves externes, mais souvent il doit faire
des choix pour ne pas multiplier les collisions de libellés: le noeud label
lui donne un placement prioritaire pour la zone ayant des enclaves externes
(des îles disjointes), et dans certains cas le libellé n'est pas approprié
sur la sous-zone la plus grande quand c'est en fait le nom de la plus
petite sous-zone qui a été étendu pour couvrir également une zone voisine
mais disjointe plus grande.

Sinon un moteur de rendu peut avoir du mal à gérer la complexité de
certains polygones fortement fragmentés avec de nombreuses enclaves. La
géométrie fait que le calcul d'un placement de libellé devient très
compliqué dans de telles zones, alors que le nœud label, correctement placé
dans la zone (et pas sur ses bordures) facilite énormément la tâche, même
si ensuite le moteur de rendu peut encore ajuster cette position en restant
dans la même zone contiguë autant que possible, s'il y a encore des
collisions avec des libellés voisins.

Quand on est aux niveaux de zoom plus avancés, le nœud libellé central dans
une zone n'est pas utile (il est plutôt nuisible) si on peut placer les
libellés le long des frontières. Et là encore on ne sert pas non plus des
attributs du noeud, seulement de ceux de la zone. En pratique on admet un
"name=*" sur de tels nœuds s'ils ne servent pas à autre chose pour des
éléments plus ponctuels mais cette dernière praique c'est déconseillée : un
objet à cartographier, un élément, car rien ne garantit qu'un autre objet
ponctuel ayant ses attributs propres soient encore approprié comme label
d'une zone plus grande qui le contient (les deux pourraient avoir des noms
différents). Bref pas besoin de "name:lang=*" sur ces noeuds.

Ces nœuds "labels" peuvent être des "place=*" mais pas nécessairement de
même nom (on a des cas comme les "place=village" ayant leur nom local
propre différent de celui de la commune qui les inclue, et je ne voit pas
pourquoi le "label" d'une commune devrait reprendre le nœud "place=*" du
village, ou un nœud d'adresse.

Ces labels sont donc seulement des aides techniques pour palier les
difficultés des moteurs de rendu pour nommer les zones (polygones et
relations), et ne sont pas des données en elles-mêmes. Je pense même que
dans de nombreux cas, les nœuds "place=*" sont inutiles et plutôt
polluants, si les objets sont mieux décrits par des surfaces polygonales ou
relations. Mais là encore si on en a gardé c'est parce que certains vieux
outils ne savent pas utiliser les polygones ou relations et ne recherchent
que des noeuds ou des polygones fermés simples et de petite taille.


Le 22 février 2018 à 22:33,  a écrit :

> Ce que dit Philippe est évidemment faux : Nominatim sait évidemment
> trouver les points et pas seulement les restaurants etc. en notation
> ponctuelle.
>
> C'est seulement si on veut avoir l'information en cliquant que l'on aura
> pas la réponse (ou qu'elle manquera dans la partie "Enclosing Features"),
> donc oui une zone délimitée, même floue c'est mieux mais un noeud c'est
> déjà mieux que rien.
> Il correspondra au nœud de type label d'une relation. Et avec une notion
> type capital/admin_level on peut savoir à quel niveau l'afficher.
>
>
> Le 22/02/2018 à 12:40, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> Un node est introuvable sur une carte, impossible à représenter quel que
> soit le niveau de zoom... On doit pouvoir tracer quelquechose estimatif
> donnant une idée correcte de l'étendue (j'ai donné l'exemple des communes
> africaines ou des frontières terrestres des émirats ou les baies maritimes,
> on ne s'en sort pas du tout avec un simple noeud. On peut donner d'autres
> exemples avec les massifs montagneux.
> Cela concerne autant les boundary=* (même administrative), natural=*,
> water=*
> Un tag supplémentaire devrait être défini et le moteur de rendu devrait
> pouvoir s'adapter pour ne pas tracer un trait trop marqué comme absolu.
> Pour les frontières administratives, le rendu serait des tirets discontinus
> suffisamment espacés.
>
> Le 22 février 2018 à 12:32, Francescu GAROBY  a écrit
> :
>
>> À défaut de frontières bien 

Re: [OSM-talk-fr] Zones géographiques informelles

[Philippe Verdy]

Je n'ai pas dit que Nominatim ne les trouvait pas. Juste qu'il ne savait
pas les utiliser pour associer des objets qui sont situés dans les zones
ayant ce nom indiqué seulement sur un point, s'il n'y avait aucune surface
associée.

Bref je maintiens !!! Un nœud ne suffit pas du tout. Tu viens d'ajouter
toi-même qu'il fallait une relation pour l'associer comme label. Il reste
donc à définir la géométrie de la zone, donc un polygone "flou" et le
problème est revenu au point de départ, et a-t-on alors besoin de ce nœud ?
pas du tout !


Le 22 février 2018 à 22:33,  a écrit :

> Ce que dit Philippe est évidemment faux : Nominatim sait évidemment
> trouver les points et pas seulement les restaurants etc. en notation
> ponctuelle.
>
> C'est seulement si on veut avoir l'information en cliquant que l'on aura
> pas la réponse (ou qu'elle manquera dans la partie "Enclosing Features"),
> donc oui une zone délimitée, même floue c'est mieux mais un noeud c'est
> déjà mieux que rien.
> Il correspondra au nœud de type label d'une relation. Et avec une notion
> type capital/admin_level on peut savoir à quel niveau l'afficher.
>
>
> Le 22/02/2018 à 12:40, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> Un node est introuvable sur une carte, impossible à représenter quel que
> soit le niveau de zoom... On doit pouvoir tracer quelquechose estimatif
> donnant une idée correcte de l'étendue (j'ai donné l'exemple des communes
> africaines ou des frontières terrestres des émirats ou les baies maritimes,
> on ne s'en sort pas du tout avec un simple noeud. On peut donner d'autres
> exemples avec les massifs montagneux.
> Cela concerne autant les boundary=* (même administrative), natural=*,
> water=*
> Un tag supplémentaire devrait être défini et le moteur de rendu devrait
> pouvoir s'adapter pour ne pas tracer un trait trop marqué comme absolu.
> Pour les frontières administratives, le rendu serait des tirets discontinus
> suffisamment espacés.
>
> Le 22 février 2018 à 12:32, Francescu GAROBY  a écrit
> :
>
>> À défaut de frontières bien définies, un node, placé à peu près au centre
>> de la zone concernée, ça n'irait pas ?
>>
>>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Rural US: Correcting Original TIGER Imported Ways

[Richard Welty]

On 2/22/18 11:57 AM, Greg Troxel wrote:
>> For the US, however, you'd want to do something other than just
>> "downgrading to track".  There are a couple of options I suspect:
> In the US, treating an unpaved road as "track" does not seem right.
> Besides the surface issue, there is a very strong notion of legal status
> between a "road" (often on its own parcel, traffic laws apply)and a
> "track" (just a place where you could drive within some larger lot, and
> often considered that traffic laws do not apply).
a very large percentage of the road network in the corn belt of the US
consists of very well maintained gravel surfaced roads. they are absolutely
not tracks and routinely support heavy farm equipment.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


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

Re: [OSM-talk-fr] recherche autorisation pour ortho Bordeaux et Languedoc-Roussillon

[Thomas Gratier]

Bonjour,

En parlant d'orthos, voir
http://professionnels.ign.fr/orthohr-par-departements#tab-3
Le seul truc que je comprend pas est le rôle d'un ortho 2012 sur LR quand
on est sensé avoir accès aux ortho IGN pour contribuer (
http://openstreetmap.fr/bdortho)
Je me trompe?


Cordialement

Thomas

Le 22 février 2018 à 14:21, Vincent Bergeot  a écrit :

> Le 22/02/2018 à 13:35, marc marc a écrit :
>
>> Bonjour,
>>
>> je continue la remise en ordre des couches eli/iD <> josm
>> Pour 2 couches, je ne trouve pas la mention de la licence permettant de
>> l'utiliser dans osm :
>> Bordeaux 2016 (ajout anonyme dans josm il y a 5 mois)
>> Languedoc-Roussillon 2012 (ajout par Ptigrouick dans josm il y a 3 ans)
>>
>
> sans doute obsolète surtout ?
> http://geocatalogue.siglr.org/geonetwork/srv/fr/metadata.sho
> w?uuid=4531ef8b-ae5e-4915-9af0-6419b737d47d
>
> je ne suis pas sur de tout bien comprendre mais je dirais que le 2016 est
> disponible ?
>
> à plus
>
>
>
>
>
>
>> Si quelqu'un a l'info :)
>>
>> Cordialement,
>> Marc
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Vincent Bergeot
>
>
>
> ___
> 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-ec] Mejoras a la red de carreteras en Ecuador

[Andrew Wiseman]

Hola Daniel,

Muchas gracias por la explicación. Arreglaremos esos y comenzaremos a repasar 
los otros. Mencionaste ciudades y zonas rurales que no están mapeadas y errores 
topológicos, ¿tienes sugerencias o lugares que recomiendas? 

Gracias y saludos,

Andrew 


Andrew Wiseman |  Maps | andrew_wise...@apple.com 



> On Feb 22, 2018, at 5:34 PM, Daniel Orellana  
> wrote:
> 
> Gracias Andrew por tu pronta respuesta!
> 
> En las calles mencionadas (Sucre y Bolivar) la tipología es la misma que 
> todas las calles del sector, con un solo sentido de circulación. La jerarquía 
> de las calles no se determina en función de la cantidad de tráfico (que es 
> variable) y menos aún con los datos de una fuente como STRAVA que tiene un 
> sesgo socioeconómico muy fuerte y está principalmente orientada a actividades 
> deportivas.
> 
> He seguido encontrando otros ejemplos donde se ha degradado de vías 
> secundarias a terciarias en Cuenca.
> https://www.openstreetmap.org/way/46227733/history 
> 
> 
> Por favor tengan en cuenta que ha tomado mucho tiempo lograr tener un acuerdo 
> sobre las etiquetas e implementarlas en diversas ciudades. Este tipo de 
> cambios deben ser siempre consultados con la comunidad. El conocimiento local 
> es el más útil en OpenStreetMap. El objetivo de todos es tener un mapa lo más 
> parecido posible a la realidad y eso se logra principalmente con el 
> conocimiento de las personas que viven en el lugar. Realmente estamos 
> contentos que Apple y TELNAV cualquier otra empresa pueda apoyar para mejorar 
> el mapa, pero es imprescindible que se incluya a la comunidad local en estos 
> cambios. Sobre todo en lugares bien mapeados, es ilógico que se cambien 
> atributos de vías que ya han pasado por varios procesos de discusión.
> 
> Por el momento te rogaría que reviertan todos los cambios de jerarquías de 
> vías que ha hecho el equipo de Apple en la ciudad de Cuenca (nosotros 
> validamos estas etiquetas hace más de un año). Así mismo recomiendo que en 
> los cambios futuros consulten a la comunidad o coloquen avisos de revisión 
> para que usuarios con conocimiento local las validen.
> 
> Creo que su colaboración puede centrarse en otros esfuerzos: por ejemplo en 
> ciudades o zonas rurales donde que no están mapeadas, corregir errores 
> topoloógicos,  utilizar los algoritmos desarrollados para extraer los 
> footprints de los edificios,  incorporar información de POIs a partir de sus 
> bases de datos, etc. 
> 
> Muchas gracias por tu comprensión y espero que podamos seguir colaborando. 
> 
> 
> ___
> Daniel Orellana, PhD. 
> Profesor Principal
> Universidad de Cuenca
> 
> >> Consulta mi agenda 
> >> 
> >> Publicaciones en Google Scholar 
> >> 
> >> Perfil en ResearchGate 
> >> 
> >> Investigación en LlactaLAB 
> >> Investigación en iDRHICA 
> 2018-02-22 16:32 GMT-05:00 Andrew Wiseman  >:
> Hola Daniel,
> 
> Gracias por su mensaje. Podemos cambiarlos pero tengo una pregunta sobre el 
> primero ejemplo: el wiki de normalización dice que tertiary es "Avenidas 
> urbanas pequeñas / Calles grandes” y "Sin separación entre sentidos de 
> circulación, con un carril por cada sentido de circulación. Más importantes 
> que las calles normales.” Calles Sucre y Simón Bolívar tienen más tráfico por 
> Strava GPS, y por eso me parece que son más importantes que las calles 
> normales. Una captura de pantalla de JOSM:
> 
> Por favor déjame saber lo que piensas.
> 
> 
> 
> 
> Saludos,
> 
> Andrew
> 
> Andrew Wiseman |  Maps | andrew_wise...@apple.com 
> 
> 
> APPLE CONFIDENTIAL
> This message (including attachments if any) is for the private use of the 
> addressee only and may contain confidential or privileged information. If you 
> have received this message by mistake please notify the sender by return 
> e-mail and delete this message and any attachments from your system. Any 
> unauthorized use or dissemination of this message, and any attachments in 
> whole or in part is strictly prohibited.
> 
> 
> 

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

[OSM-talk] SharedStreets open platform is built on top of OSM

[Eugene Alvin Villar]

I came across this article describing SharedStreets which is intended to be
an open platform for city governments and private entities like Uber to
share street-related data like traffic data, taxi/cab pickup points, and
the like. The chief architect for SharedStreets says: "What GTFS does for
transit, we’re doing for streets."

https://www.citylab.com/transportation/2018/02/a-powerful-map-promises-to-help-cities-keep-streets-free/553739/

Here's the SharedStreets website:
http://sharedstreets.io/

And it links to the SharedStreets GitHub repository which explains the
technical details.
https://github.com/sharedstreets/sharedstreets-ref-system

It seems that they can ingest OSM (or another set of geodata) to generate
an abstracted topology of the street network based on street intersections
and the street segments connecting them.

Here is their FAQ with respect to OSM:

*How does this relate to OpenStreetMap? (Or, doesn't OSM already do this?)*
>
> SharedStreets complements OpenStreetMap. OSM does not attempt to provide
> stable IDs, and complex OSM ways make many applications difficult to build
> using raw OSM data.
>
> SharedStreets provides a layer of abstraction on top of OSM, allowing
> users to work with the topology of OpenStreetMaps data without dealing with
> the details how OSM ways are encoded.
>
> By providing direct references to OSM way and node IDs users can always
> query and relate SharedStreets references back to the underlying OSM data
> where needed.
>
> We believe that SharedStreets will allow users to more rapidly improve
> OpenStreetMap data by making it easier to identify missing streets, or
> opportunities to improve street geometry and connectivity.
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-es] Calles muy estrechas

[Rafael Avila Coya]

Hola, Daniel:

Naturalmente, mapeamos lo que es correcto, nunca para el renderizador ;)

En mi opinión, una calle puede ser residencial aún cuando no puedan 
pasar coches, pues es posible que el tránsito de motos siga siendo 
posible y permitido.


En todo caso, si se opta por highway=pedestrian para algún caso, la web 
de esa etiqueta dice exactamente:


"For small paths which are too small for cars to pass (no real streets) 
use highway=footway instead.". Es decir: "no real streets". Los paths 
(senderos y equivalentes) no son calles, aunque hay senderos y caminos 
en algún parque que llevan nombre de calle (ejemplo de El Retiro de 
Madrid [1]). Por lo tanto no creo que sea correcto poner path para lo 
que la gente interpretaría como calle, fuese esta estrecha o no, 
accesible a vehículos o a peatones. Según el caso tendremos 3 
posibilidades: residential, pedestrian y living_street (si no me olvido 
ninguna).


En todo caso, es difícil encontrar una respuesta global a esta cuestión 
(y muchas otras relacionadas con highway). Hay zonas del mundo que 
tienen su propia variante de interpretación y uso de estas etiquetas, 
como son los casos de Japón y de África, como dos ejemplos que me vienen 
a la cabeza.


Un saludo,

Rafael.

[1] https://www.openstreetmap.org/#map=18/40.41762/-3.68265

On 23/02/18 00:17, dcapillae wrote:

Estos días estoy revisando el callejero de los pueblos de Málaga para
preparar la importación de edificios y direcciones del Catastro [1], y he
podido comprobar que muchas calles estrechas de los pueblos de Málaga, de
uso fundamentalmente peatonal y por donde no pasa un coche, están mapeadas
como «highway=residential».

Etiquetarlas como «highway=residential» no me parece correcto, ya que no se
ajusta a la definición de este tipo de vías [2]. Tampoco me parece correcto
etiquetarlas como calles peatonales propiamente dichas, del tipo
«highway=pedestrian». Lo correcto sería mapearlas como «highway=footway»
[3].

En la página de la etiqueta «highway=pedestrian» se dice que las calles
peatonales demasiado estrecha como para que eventualmente pueda circular un
coche deben etiquetarse como «highway=footway» [4]. El único inconveniente
que le veo a etiquetar las calles estrecha de los pueblos con
«highway=footway» es que, a día de hoy, el nombre de la calle no se muestra
en el mapa del sitio web de OSM. Obviando esta cuestión, creo que sería el
etiquetado más correcto.

Respecto a «highway=service», yo no la usaría para mapear ninguna calle como
tal. Su uso se debería limitar a vías de servicio. Si se trata de una calle
de pueblo, más ancha o más estrecha pero por la que cabe un coche, en ese
caso sí me parece correcto mapearla como «highway=residential», siempre y
cuando sea una calle como tall, con nombre reconocido y reconocible, y no
una simple vía de servicio [4].


[1]
https://wiki.openstreetmap.org/wiki/ES:Catastro_español/Importación_de_edificios
[2] https://wiki.openstreetmap.org/wiki/ES:Tag:highway=residential
[3] https://wiki.openstreetmap.org/wiki/ES:Tag:highway=footway
[4] https://wiki.openstreetmap.org/wiki/ES:Tag:highway=pedestrian
[5] https://wiki.openstreetmap.org/wiki/ES:Tag:highway=service



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

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



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

Re: [Talk-es] Calles muy estrechas

[dcapillae]

Estos días estoy revisando el callejero de los pueblos de Málaga para
preparar la importación de edificios y direcciones del Catastro [1], y he
podido comprobar que muchas calles estrechas de los pueblos de Málaga, de
uso fundamentalmente peatonal y por donde no pasa un coche, están mapeadas
como «highway=residential».

Etiquetarlas como «highway=residential» no me parece correcto, ya que no se
ajusta a la definición de este tipo de vías [2]. Tampoco me parece correcto
etiquetarlas como calles peatonales propiamente dichas, del tipo
«highway=pedestrian». Lo correcto sería mapearlas como «highway=footway»
[3].

En la página de la etiqueta «highway=pedestrian» se dice que las calles
peatonales demasiado estrecha como para que eventualmente pueda circular un
coche deben etiquetarse como «highway=footway» [4]. El único inconveniente
que le veo a etiquetar las calles estrecha de los pueblos con
«highway=footway» es que, a día de hoy, el nombre de la calle no se muestra
en el mapa del sitio web de OSM. Obviando esta cuestión, creo que sería el
etiquetado más correcto.

Respecto a «highway=service», yo no la usaría para mapear ninguna calle como
tal. Su uso se debería limitar a vías de servicio. Si se trata de una calle
de pueblo, más ancha o más estrecha pero por la que cabe un coche, en ese
caso sí me parece correcto mapearla como «highway=residential», siempre y
cuando sea una calle como tall, con nombre reconocido y reconocible, y no
una simple vía de servicio [4].


[1]
https://wiki.openstreetmap.org/wiki/ES:Catastro_español/Importación_de_edificios
[2] https://wiki.openstreetmap.org/wiki/ES:Tag:highway=residential
[3] https://wiki.openstreetmap.org/wiki/ES:Tag:highway=footway
[4] https://wiki.openstreetmap.org/wiki/ES:Tag:highway=pedestrian
[5] https://wiki.openstreetmap.org/wiki/ES:Tag:highway=service



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

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

Re: [OSM-talk] Mapping rivers that flow into/through lakes?

[Christoph Hormann]

On Thursday 22 February 2018, Rory McCann wrote:
>
> What's the best way to map rivers that flow into lakes, especially
> when another river flows through it? Should they be connected?
>
> [...]

This has been discussed in the past occasionally and IIRC there was 
never full agreement on the matter.  A few things that are important to 
consider:

* The question if a river flows through a lake or if it enters a lake 
and ends there is not generally something that can be answered 
verifiably.
* In well mapped areas where a lake has one large outflow and only one 
or a few similarily large inflows they are often connected.
* In most cases with larger lakes smaller inflows are not connected.
* In contrast to riverbank polygons where there is in principle a well 
established rule where to place the waterway (the thalweg) there is no 
established rule how rivers that are connected within a lake are to be 
placed or connected.
* There is also no established rule if waterways within a lake get the 
name and other tags from the tributaries they connect or if they are to 
be without name tag.  Both variants are common.
* The vast majority of waterbody imports import without connectivity, 
even if connected data is available like in the US and Canada.

Part of the problem is of course that the task of generating waterway 
connectivity within a water area or supplementing an incomplete 
connectivity are cumbersome mechanical tasks.  So the ultimate question 
probably is if this is something editors should provide support to 
produce automatically or if it is something that data users should 
generate automatically as needed.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-ec] Mejoras a la red de carreteras en Ecuador

[Daniel Orellana]

Gracias Andrew por tu pronta respuesta!

En las calles mencionadas (Sucre y Bolivar) la tipología es la misma que
todas las calles del sector, con un solo sentido de circulación. La
jerarquía de las calles no se determina en función de la cantidad de
tráfico (que es variable) y menos aún con los datos de una fuente como
STRAVA que tiene un sesgo socioeconómico muy fuerte y está principalmente
orientada a actividades deportivas.

He seguido encontrando otros ejemplos donde se ha degradado de vías
secundarias a terciarias en Cuenca.
https://www.openstreetmap.org/way/46227733/history

Por favor tengan en cuenta que ha tomado mucho tiempo lograr tener un
acuerdo sobre las etiquetas e implementarlas en diversas ciudades. Este
tipo de cambios deben ser siempre consultados con la comunidad. El
conocimiento local es el más útil en OpenStreetMap. El objetivo de todos es
tener un mapa lo más parecido posible a la realidad y eso se logra
principalmente con el conocimiento de las personas que viven en el lugar.
Realmente estamos contentos que Apple y TELNAV cualquier otra empresa pueda
apoyar para mejorar el mapa, pero es imprescindible que se incluya a la
comunidad local en estos cambios. Sobre todo en lugares bien mapeados, es
ilógico que se cambien atributos de vías que ya han pasado por varios
procesos de discusión.

Por el momento te rogaría que reviertan todos los cambios de jerarquías de
vías que ha hecho el equipo de Apple en la ciudad de Cuenca (nosotros
validamos estas etiquetas hace más de un año). Así mismo recomiendo que en
los cambios futuros consulten a la comunidad o coloquen avisos de revisión
para que usuarios con conocimiento local las validen.

Creo que su colaboración puede centrarse en otros esfuerzos: por ejemplo en
ciudades o zonas rurales donde que no están mapeadas, corregir errores
topoloógicos,  utilizar los algoritmos desarrollados para extraer los
footprints de los edificios,  incorporar información de POIs a partir de
sus bases de datos, etc.

Muchas gracias por tu comprensión y espero que podamos seguir colaborando.


___
Daniel Orellana, PhD.
Profesor Principal
Universidad de Cuenca

>> Consulta mi agenda

>> Publicaciones en Google Scholar

>> Perfil en ResearchGate

>> Investigación en LlactaLAB 
>> Investigación en iDRHICA


2018-02-22 16:32 GMT-05:00 Andrew Wiseman :

> Hola Daniel,
>
> Gracias por su mensaje. Podemos cambiarlos pero tengo una pregunta sobre
> el primero ejemplo: el wiki de normalización dice que tertiary es "Avenidas
> urbanas pequeñas / Calles grandes” y "Sin separación entre sentidos de
> circulación, con un carril por cada sentido de circulación. Más importantes
> que las calles normales.” Calles Sucre y Simón Bolívar tienen más tráfico
> por Strava GPS, y por eso me parece que son más importantes que las
> calles normales. Una captura de pantalla de JOSM:
>
> Por favor déjame saber lo que piensas.
>
>
>
>
> Saludos,
>
> Andrew
>
> Andrew Wiseman |  Maps | andrew_wise...@apple.com
>
> APPLE CONFIDENTIAL
> This message (including attachments if any) is for the private use of the
> addressee only and may contain confidential or privileged information. If
> you have received this message by mistake please notify the sender by
> return e-mail and delete this message and any attachments from your system.
> Any unauthorized use or dissemination of this message, and any attachments
> in whole or in part is strictly prohibited.
>
>
>
>
> On Feb 22, 2018, at 8:01 AM, Daniel Orellana  ec> wrote:
>
> Hola Andrew.
>
> Te comento que hemos encontrado algunos problemas en las ediciones que
> está haciendo tu equipo, en particular el usuario TyFly. He detectado que
> varias calles en la ciudad de Cuenca se han cambiado las etiquetas
> injustificadamente
>
> Ej 1: Calle sucre es residential y se ha cambiado a tertiary
> https://www.openstreetmap.org/way/337277984
>
> Ej 2: Calle Roberto Crespo Toral es Secondary y se ha cambiado a tertiary.
> https://www.openstreetmap.org/way/42143234
>
> Por favor indica a tu equipo que revierta estos cambios y que consulte acá
> antes de realizar este tipo de cambios ya que nos ha costado mucho tiempo
> llegar a consensos.
>
> Una ayuda muy importante para nosotros sería si se puede extender el
> trabajo que están haciendo sobre building footprints a Ecuador.
>
>
> Saludos
> Daniel.
>
> ___
> Daniel Orellana, PhD.
> Profesor Principal
> Universidad de Cuenca
>
> >> Consulta mi agenda
> 
> >> Publicaciones en Google Scholar
> 

Re: [Talk-it] leisure=pitch come inner?

[liste DOT girarsi AT posteo DOT eu]

Il 22/02/2018 15:39, demon.box ha scritto:

ciao, se trovo già mappata un'area molto estesa come multipoligono
landuse=residential e sopra questa vado a mappare alcune aree leisure=pitch
devo metterle come membri con ruolo inner?
grazie
--enrico



Io multipoligoni in questi casi non li ho mai fatti, comunque si vedono 
renderizzati senza problemi, qui un esempio mio:


http://www.openstreetmap.org/#map=17/46.05607/11.46767


--
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [Talk-at] "geocodec/Socke/Johann Haag" stummschalten

[Friedrich Volkmann]

On 22.02.2018 19:54, "Peter Müller" wrote:

weil ich meine Popcorn gerne bei einer Diskussion von alten Herrn esse ;-)
Du hast in deiner Zeitmaschine die falsche Taste gedrückt, die Club 2 mit 
Nenning liefen 1976-95. :-p


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

[OSM-talk] Mapping rivers that flow into/through lakes?

[Rory McCann]

Hi mappers,

What's the best way to map rivers that flow into lakes, especially when
another river flows through it? Should they be connected?

When a river flows through a lake, you can map a waterway=river way
through it, to be "topoligcally complete". Or would it be better to add
ways (w/o waterway tag) to the river relation?

When a tributary river joins another, join the central waterway=river
ways together. But what if a river drains into a lake with a  "central
river" through it? Should you connect that river to the central river?
It makes topological sense.

If you asked someone "Where does this river end?" they'd probably point
to where it joins the lake. Connecting the river to the "central river"
breaks this. And it can result in odd long ways. I might have gone a
little OTT here (
http://tools.geofabrik.de/osmi/?view=water=27.98062=-16.95179=11
) or here (
http://tools.geofabrik.de/osmi/?view=water=-8.26705=52.99047=11
).

Without joining the ways, then a data consumer will have to do
complicated extra processing to deduce that one river "flows into" the
other? (River X ends on the shore of a lake, River Y flows through the
lake, so connect X to Y). Is that "good enough"?

Thoughts?

Rory

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

Re: [Talk-at] "geocodec/Socke/Johann Haag" stummschalten

[Rudolf Mayer]

On 02/22/2018 01:49 PM, Johann Haag wrote:

wenn du kompetenztechnisch nicht mitreden kannst, was machst du dann hier in 
einem OSM Forum. Dir ist aber schon bewusst dass Deine Stimme hier als 
Vollwertig in OSM Entscheidungen gilt.



Seit wann muss man in Österreich Kompetenz haben, um was (mit)bestimmen 
zu können? :-)


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

Re: [OSM-talk-fr] Zones géographiques informelles

[osm . sanspourriel]

Ce que dit Philippe est évidemment faux : Nominatim sait évidemment 
trouver les points et pas seulement les restaurants etc. en notation 
ponctuelle.


C'est seulement si on veut avoir l'information en cliquant que l'on aura 
pas la réponse (ou qu'elle manquera dans la partie "Enclosing 
Features"), donc oui une zone délimitée, même floue c'est mieux mais un 
noeud c'est déjà mieux que rien.


Il correspondra au nœud de type label d'une relation. Et avec une notion 
type capital/admin_level on peut savoir à quel niveau l'afficher.


Le 22/02/2018 à 12:40, Philippe Verdy - verd...@wanadoo.fr a écrit :
Un node est introuvable sur une carte, impossible à représenter quel 
que soit le niveau de zoom... On doit pouvoir tracer quelquechose 
estimatif donnant une idée correcte de l'étendue (j'ai donné l'exemple 
des communes africaines ou des frontières terrestres des émirats ou 
les baies maritimes, on ne s'en sort pas du tout avec un simple noeud. 
On peut donner d'autres exemples avec les massifs montagneux.
Cela concerne autant les boundary=* (même administrative), natural=*, 
water=*
Un tag supplémentaire devrait être défini et le moteur de rendu 
devrait pouvoir s'adapter pour ne pas tracer un trait trop marqué 
comme absolu. Pour les frontières administratives, le rendu serait des 
tirets discontinus suffisamment espacés.


Le 22 février 2018 à 12:32, Francescu GAROBY > a écrit :


À défaut de frontières bien définies, un node, placé à peu près au
centre de la zone concernée, ça n'irait pas ?



___
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-lv] neasfaltētu ceļu attēlošana osm.org

[Pēteris Brūns]

Nu pārtraukto līniju eksperimenti seguma attēlošanai nešķiet pārāk ok.
Asociatīvi tos uztver kā - remonts, neuzbūvēts, plānots vai sliktā stāvoklī
Lec acīs kā brīdinājums - uzmanies!
Nākot no redzes īpatņiem un smalku toņu neatšķīrējiem, tad tur būtu kāds
labs krāsu izjūtu un uztveres speciālists jānoķer, varētu iztikt ar kādiem
2 krāsu toņiem un ceļa malu līniju platuma variācijām - viegli uztvert un
nav raibs. Jo patiesībā paved/unpaved, manuprāt, vajag tikai secondary,
tertiary un unclassified ceļiem.

2018-02-22 18:38 GMT+02:00 Rihards :

> Diskusija ir atsākusies, ir daži piedāvājumi - pie tam, ar Latvijas
> datiem :)
>
> https://github.com/gravitystorm/openstreetmap-
> carto/issues/110#issuecomment-367668091
> --
>  Rihards
>
> ___
> Talk-lv mailing list
> Talk-lv@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-lv
>



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

[OSM-talk-fr] cycleway=track et bifurcations

[osm . sanspourriel]

Si on a une route principale avec une piste à côté taguée 
cycleway=track, peut-on indiquer que lors d'un carrefour que la voie 
n'est pas empruntable depuis la piste cyclable ?


Si la route débouchant sur la route principale est du côté opposé, comme 
c'est une piste et non une bande cyclable, est-ce que ça ne va pas de soi ?


Sauf qu'au niveau du rendu sur la carte, comme au niveau des moteurs de 
navigation certaines subtilités échappent.


Jean-Yvon

N.B. : je ne suis pas spécialement partisan de cycleway=track, je 
cherche juste des cas incompatibles avec une telle description, au moins 
des cas où la représentation est plus difficile qu'avec une voirie 
tracée en propre (par exemple on pourrait mettre des restrictions pour 
dire explicitement que c'est impossible.


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

Re: [Talk-it] [Imports] Fwd: Re: Sabbioneta buildings import

[Martin Koppenhoefer]

sent from a phone

> On 22. Feb 2018, at 14:41, Andrea Musuruane  wrote:
> 
> * You should also add building=yes to bell towers.


I would suggest building=bell_tower


Cheers,
Martin 

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

[OSM-talk-be] Fwd: [OSM-talk] Highway=trunk : harmonization between countries ?

[joost schouppe]

Hi,

Not wanting to change current consensus in Belgium, but I wonder how close
this would be to current mapping practice in Belgium, and if it would be a
way of thinking that could help in some current edge cases.

-- Forwarded message --
From: Fernando Trebien 
Date: 2018-02-15 19:14 GMT+01:00
Subject: Re: [OSM-talk] Highway=trunk : harmonization between countries ?
To: t...@openstreetmap.org


Landing on this discussion several months late. I've just heard of it
by reading a wiki talk page [1].

Since 13 February 2009, the wiki [2] criticises highway classification
as problematic/unverifiable. This has also been subject to a lot of
controversy (and edit wars) in my local community (Brazil), especially
regarding the effect of (lack of) pavement.

In trying to achieve greater consensus some years ago, I decided to
seek opinions elsewhere and finally I arrived at this scheme [3] which
I think is very useful, if not perfect yet. It can be easily
summarised like this:
- trunk: best routes between large/important cities
- primary: best routes between cities and above
- secondary: best routes between towns/suburbs and above
- tertiary: best routes between villages/neighbourhoods and above
- unclassified: best routes between other place=* and above

For example, the best route between two villages would be at least
tertiary. So would be the best route between a village and a town or a
city. Parts of this route might have a higher class in case they are
part of a route between more important places.

It surely raises the problem of determining optimal routes. Maybe a
sensible criterion would be average travel time without traffic
congestion. A number of vehicles may be selected for this average -
could be motorcycle+car+bus+truck, or simply car+truck.

Early results in my area [4, in Portuguese] seem promising and have
produced more consensus than any previous proposals. To me, this
method seems to:
- resist alternations in classification along the same road
- work across borders (where classification discontinuities are
expected because each country is using different classification
criteria)
- account for road network topology
- work in countries with mostly precarious/unpaved roads or
without/unknown official highway classes
- work between settlements as well as within settlements

Borderline cases are probably inescapable in any system that does not
use solely criteria that are directly verifiable - from the ground, or
from the law. Maybe, in certain developed countries, the system is so
well organized that merely checking signs/laws is sufficient. That
does not mean it is like that everywhere on the planet.

OSM has so far received a lot of input from communities in developed
countries (mostly Europe, North America and Australia) and hasn't
given much attention to less developed/organized countries. What comes
closest to this is what the HOT Team does, but the judgment of road
classification one can do from satellite images in a foreign country
is much more limited than the criteria that have been raised in this
thread so far.

I wouldn't endorse tags such as maxspeed:practical due to lack of
verifiability (it should be obvious that different types of vehicles
would achieve different practical speeds). It is better to use the
legal speed in maxspeed=* and describe the practical reason for a
lower speed using surface=*, smoothness=*, and, who knows, maybe the
not yet approved hazard=* [5] (though that is intended for signed
hazards, not subjective/opinionated hazards).

For the sake of long-term sanity, I also wouldn't mix the purpose of
one tag with the purpose of other tags. To describe the surface, there
is surface=*, smoothness=* and tracktype=*. To describe access rights,
there is access=*, foot=*, bicycle=*, motor_vehicle=*, etc. To
describe legal speed, maxspeed=*. To describe curves, there's
geometry.

Purpose, perhaps, is the main issue. What is the purpose of highway
classification? Is it to save us the work of adding extra tags? Is it
to allow the renderer to produce a cleaner output at low zoom levels?
Is it to allow routers to assume default speeds? Maybe to guide their
routing heuristics? Is it to express some sort of importance? If so,
by which perspective - urbanistic, traffic engineering, movement,
commercial value, cultural/fame, historic, some combination of those?
Should the purpose be the same in every country?

It may be interesting to also discuss the classification adopted by
other maps. I don't have a reference for Google (originally TeleAtlas)
or Here.com (originally Navteq), but Waze publishes its per-country
road classification criteria in its wiki. [6-16]

[1] https://wiki.openstreetmap.org/wiki/Talk:Tag:highway%
3Dtrunk#change_.22high_performance.22_to_.22high_importance.22
[2] https://wiki.openstreetmap.org/wiki/Verifiability#Problematic_tags
[3] https://wiki.openstreetmap.org/wiki/User:Ftrebien/Drafts/

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[Andreas Lattmann]

+1 Hai centrato il problema

Il February 22, 2018 3:45:22 PM UTC, Volker Schmidt  ha 
scritto:
>Scusate,
>
>mi sembra che mescoliamo due argomenti
>*i fatti: *
>Io ho copiato più o meno da una fonte Google, StreetView in questo caso
>*le prove che l'ho fatto: *
>come Google potrebbe dimostrare senza dubbi che io ho copiato da Google
>
>Il mio punto è che non dobbiamo copiare per non mettere a rischio il
>progetto.
>
>Tutta questa discussione è un po' come:
>C'è un cartello di limite di velocità di 50km/h.
>Uno dice: "Devo andare non più veloce di 50km/h"
>e l'altro risponde
>"Perché? La polizia non può provare che sei andato più veloce, non c'è
>un
>autovelox in quel posto!"
>
>(so che semplifico, ma gli argomenti della discussione sono su piani
>disgiunti)

Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[Andreas Lattmann]

>La prova potrebbe esser la seguente:
>Nelle foto di StreetView la via Garibaldi >appare il 20 settembre 2017,
>il 22 settembre 2017 la via Garibaldi >appare anche in OSM.
>Ma anche in questo caso dovrebbero >esserci altri elementi perché
>l'accusa tenga.

Poi ci si accorge che le foto di Google sono vecchie e si introducono degli 
errori.
Lo dico perché è capitato che un mapper Francese ha cambiato i limiti di 
velocità che avevo inserito in una superstrada, perché aveva visto su 
streetview che il limite era a X...

Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[Andreas Lattmann]

>Strano come praticamente solo persone di origine straniera difendano
>una
>certa posizione...
>

 


Non bisogna "copiare" indipendentemente se si viene beccati o meno o se sia 
lecito o meno. Google scrive "di non copiare", rispettiamo la sua volontà, è un 
suo lavoro ha il diritto umano di poter decidere cosa voler fare del frutto del 
suo lavoro. Anche se la legge ce lo dovesse permettere impariamo a rispettare 
il lavoro altrui. Non lamentiamoci poi se altre persone/società camuffano la 
"nostra" mappa per rendere difficile dimostrare che è OSM con la scusa, "ma a 
me serve una mappa con i sentieri, dove la prendo e poi tanto come fanno quelli 
di OSM a dimostrare che è loro...". Non esistono giustificazioni, non si fa. 
Punto. Vi servono le foto? Esiste OpenStreetCam o Mapillary o vi fate le foto 
per conto vostro. Non ricordate una cosa?? Fa niente, la prossima volta vi 
ricorderete di far fotografie, di prendere note più descrittive o note audio. 

Detto popolare: "Chi non ha testa, ha gambe!" 


Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

Re: [OSM-talk-fr] JOSM transfert des nœuds et pas des chemins

[osm . sanspourriel]

Le 22/02/2018 à 17:15, marc marc - marc_marc_...@hotmail.com a écrit :


Bonjour,

Le 22. 02. 18 à 16:48, Rpnpif a écrit :

Je suis novice dans JOSM.
https://www.openstreetmap.org/changeset/56579562
Qu'en pensez-vous ?

J'annule et on repart de 0 ? :-)

Cordialement,
Marc

Je suis d'accord avec Marc, notamment la dernière proposition.
Faire un import massif avec un outil que l'on ne connaît pas, faut être 
un peu gonflé ;-).
J'ai pris un point au hasard 
https://www.openstreetmap.org/node/5429129253#map=17/47.67817/-0.94895

Je vois que c'est à proximité immédiate de La Verzée.
Sur le site indiqué c'est un point de La Verzée.
Donc deux possibilités :
- l'info est meilleure
- l'info est moins bonne (décalée ou pire).

Dans le second cas la solution est simple ;-)
Dans le premier il faut importer le bout de ruisseau et remplacer le 
bout équivalent existant (pour ne pas perdre les attributs).

Ce n'est pas une opération triviale : il faut bien connaître JOSM et OSM.
Donc à ne pas faire seule, cherche quelqu'un du côté de chez toi ou tu 
sauvegarde les modifications localement et tu demandes à quelqu'un sur 
la liste par exemple de vérifier.


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

Re: [Talk-ca] Issues with an Ottawa school

[Frederik Ramm]

Apologies everyone (and thanks John for stepping forward) - I have the
wrong Ottawa. My school isn't even in Canada. Sorry for the noise, I'll
have to ask elsewhere.

On 02/22/2018 07:58 PM, Frederik Ramm wrote:
> Hi,
> 
> DWG has received a complaint about a fictional village in Africa,
> 
> https://www.openstreetmap.org/#map=18/16.36752/-3.47617
> 
> and after investigation it turns out that a total of 120 user accounts
> have been created on January 25th, using email addresses that point to
> one particular unified school district in Ottawa.
> 
> 76 of these have made edits, some of which are legitimate tracings of
> buildings in Africa, but the majority are "funny" edits like the ones
> you see in the link above, in various places in Africa and occasionally
> the US. Objects with names like "Get dunked on", "The Ocean of
> Awsomeness with Vianey, Sarah, Maddy and Aubrey not Abby", "the abanoned
> mushroom railroad", "some fenced in area", "The Monkey Park" - the usual
> teenage stuff.
> 
> I don't have the time to sort the good from the bad, and given that none
> of the pupils/students were active after January 26th, I'll probably
> revert the lot.
> 
> Would anybody be willing to try and make contact with the school
> district in question, and try to find out who is responsible? It is
> certainly a good idea to introduce young people to OSM, but apparently
> with 120 in one go, teachers/instructors were unable to provide the
> necessary guidance for this to become a success. (I have not seen any
> attempts of organised cleanup either.)
> 
> It would be good if the organisers responsible had a contact into the
> Ottawa OSM community so they could ask for support next time they plan
> something like this.
> 
> (As a side note, most accounts seem to have been set up using real
> names, which perhaps also is not best practice for teenage editing,
> *especially* if most of the data contributed is actually detrimental to
> OSM.)
> 
> If someone steps forward, I would furnish them with details in a
> personal email so as to avoid publicly tarnishing the reputation of the
> school in question ;)
> 
> Our aim is not to accuse, but to help them understand the issue, and do
> better next time. It would be ideal if whoever steps forward possesses
> the diplomacy skills necessary to get that across.
> 
> Bye
> Frederik
> 

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

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

Re: [OSM-talk-fr] Zones géographiques informelles

[Philippe Verdy]

Bien sûr que non car une commerce ou une maison c'est TRES localisé et même
très précisément, ce qui n'est pas le cas de grandes zones dont le seul
point sera masqué par tout le reste puisqu'e ces points n'ont aucune
étendue définie et qu'on n'a même pas moyen de zoomer dessus précisément la
position est impossibel à déterminer saus si on sait déjà où c'est sensé
être (dans ce cas on ne cherche pas dans la base, on utilise bien une autre
connaissance stockée ailleurs).
Admettons que tu trouvent le point dans une recherche sur une zone très
étendue, parmi des milliers ou des millions d'autres (ce qui n'est
justement pas garanti), tu en fais quoi ? Tu zoomes dessus et tu n'a aucun
moyen de relier ce point avec une zone très grande pour lequel il est
attaché ?
Une maison un commerce, une adresse c'est facile à corréler à un point
trouvé. Mais pas du tout ici !


Le 22 février 2018 à 13:25, Francescu GAROBY  a écrit :

> Bien sûr que si, un node est trouvable sur une carte ! Sinon, on ne
> pourrait pas trouver les commerces/numéros de rue/... quand on fait une
> recherche !
>
> Francescu
>
> Le 22 février 2018 à 12:40, Philippe Verdy  a écrit :
>
>> Un node est introuvable sur une carte, impossible à représenter quel que
>> soit le niveau de zoom... On doit pouvoir tracer quelquechose estimatif
>> donnant une idée correcte de l'étendue (j'ai donné l'exemple des communes
>> africaines ou des frontières terrestres des émirats ou les baies maritimes,
>> on ne s'en sort pas du tout avec un simple noeud. On peut donner d'autres
>> exemples avec les massifs montagneux.
>> Cela concerne autant les boundary=* (même administrative), natural=*,
>> water=*
>> Un tag supplémentaire devrait être défini et le moteur de rendu devrait
>> pouvoir s'adapter pour ne pas tracer un trait trop marqué comme absolu.
>> Pour les frontières administratives, le rendu serait des tirets discontinus
>> suffisamment espacés.
>>
>> Le 22 février 2018 à 12:32, Francescu GAROBY  a
>> écrit :
>>
>>> À défaut de frontières bien définies, un node, placé à peu près au
>>> centre de la zone concernée, ça n'irait pas ?
>>>
>>>
>
>
> --
> Francescu
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-transit] GTFS integration tool (Jo)

[Barbeau, Sean]

Polyglot,
You might want to check out this project, which sounds very similar to what 
you're proposing:
https://github.com/CUTR-at-USF/gtfs-osm-sync

It's written in Java.

Sean

-Original Message-
From: talk-transit-requ...@openstreetmap.org 
[mailto:talk-transit-requ...@openstreetmap.org] 
Sent: Thursday, February 22, 2018 7:01 AM
To: talk-transit@openstreetmap.org
Subject: Talk-transit Digest, Vol 79, Issue 3

Send Talk-transit mailing list submissions to
talk-transit@openstreetmap.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.openstreetmap.org/listinfo/talk-transit
or, via email, send a message with subject or body 'help' to
talk-transit-requ...@openstreetmap.org

You can reach the person managing the list at
talk-transit-ow...@openstreetmap.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of Talk-transit digest..."


Today's Topics:

   1. GTFS integration tool (Jo)


--

Message: 1
Date: Wed, 21 Feb 2018 14:36:00 +0100
From: Jo 
To: "Public transport/transit/shared taxi related topics"

Subject: [Talk-transit] GTFS integration tool
Message-ID:

Re: [Talk-ca] Issues with an Ottawa school

[John Marshall]

Good day Frederik,

I would.

John Marshall
Ottawa


On Thu, Feb 22, 2018 at 1:58 PM, Frederik Ramm  wrote:

> Hi,
>
> DWG has received a complaint about a fictional village in Africa,
>
> https://www.openstreetmap.org/#map=18/16.36752/-3.47617
>
> and after investigation it turns out that a total of 120 user accounts
> have been created on January 25th, using email addresses that point to
> one particular unified school district in Ottawa.
>
> 76 of these have made edits, some of which are legitimate tracings of
> buildings in Africa, but the majority are "funny" edits like the ones
> you see in the link above, in various places in Africa and occasionally
> the US. Objects with names like "Get dunked on", "The Ocean of
> Awsomeness with Vianey, Sarah, Maddy and Aubrey not Abby", "the abanoned
> mushroom railroad", "some fenced in area", "The Monkey Park" - the usual
> teenage stuff.
>
> I don't have the time to sort the good from the bad, and given that none
> of the pupils/students were active after January 26th, I'll probably
> revert the lot.
>
> Would anybody be willing to try and make contact with the school
> district in question, and try to find out who is responsible? It is
> certainly a good idea to introduce young people to OSM, but apparently
> with 120 in one go, teachers/instructors were unable to provide the
> necessary guidance for this to become a success. (I have not seen any
> attempts of organised cleanup either.)
>
> It would be good if the organisers responsible had a contact into the
> Ottawa OSM community so they could ask for support next time they plan
> something like this.
>
> (As a side note, most accounts seem to have been set up using real
> names, which perhaps also is not best practice for teenage editing,
> *especially* if most of the data contributed is actually detrimental to
> OSM.)
>
> If someone steps forward, I would furnish them with details in a
> personal email so as to avoid publicly tarnishing the reputation of the
> school in question ;)
>
> Our aim is not to accuse, but to help them understand the issue, and do
> better next time. It would be ideal if whoever steps forward possesses
> the diplomacy skills necessary to get that across.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-at] "geocodec/Socke/Johann Haag" stummschalten

[Peter Müller]

Ich kann kompetenztechnisch auch nicht mitreden und gebe trotzdem meinen senf 
ab, weil ich meine Popcorn gerne bei einer Diskussion von alten Herrn esse ;-) 
und das feuer muss am brennen bleiben, hihi
Macht weiter so, ich freue mich auf Staffel zwei! 
:-P

> Gesendet: Donnerstag, 22. Februar 2018 um 13:49 Uhr
> Von: "Johann Haag" 
> An: "OpenStreetMap AT" 
> Betreff: Re: [Talk-at] "geocodec/Socke/Johann Haag" stummschalten
>
> wenn du kompetenztechnisch nicht mitreden kannst, was machst du dann hier in 
> einem OSM Forum. Dir ist aber schon bewusst dass Deine Stimme hier als 
> Vollwertig in OSM Entscheidungen gilt.  
> 
> Grüsse Johann
> osm wiki the map
> 
> Von meinem iPhone gesendet
> 
> > Am 22.02.2018 um 11:40 schrieb Marcus MERIGHI :
> > 
> > Ich kann kompetenztechnisch inhaltlich nicht mitreden; aber ich merke,
> > wenn einer immer das selbe sagt, argumentativ widerlegt wird - und
> > wieder dasselbe sagt. 
> > 
> > Netiquette ist Ihm auch egal, seine E-Mails sind muehsam zu lesen. 
> > 
> > Wenn ich so ein Verhalten erleben will dann halte ich lieber einen
> > Kletterkurs fuer Jugendliche.
> > 
> > Er ist ja so ein armes Opfer. Alle sind gegen Ihn.
> > Dunning-Kruger-Effekt. Troll.
> > 
> > https://www.mail-list.com/how-to-deal-with-trolls-in-your-listserv/
> > http://www.crydee.com/raymond-feist/faq/4164/how-to-handle-trolls-on-the-mailing-list
> > https://kotaku.com/10-former-internet-trolls-explain-why-they-quit-being-j-1722649439
> > 
> > Marcus
> > 
> > johannh...@hxg.at (Johann Haag), 2018.02.22 (Thu) 00:45 (CET):
> >> Hallo Rudi,
> >> Meine Fragestellung zur Wiener Adress Besonderheit im osm Forum war
> >> rechtzeitig und klar, aber man hat mich dort links liegen gelassen,
> >> und mich ganz offen in einen 20k Edit hineinrennen lassen. Nicht ich
> >> war jener der die Diskussion verweigert hat.
> >> Erst als ich die Sachlage anschlie??end in Eigenregie selbst eruiert
> >> hatte, heisst es pl??tzlich, das haben wir doch alles l??ngst gewusst.
> >> Das nennt man einen f??r Dumm verkaufen.
> >> 
> >> Nun nachdem eine einfache L??sung durch Mappen vorerst wenigstens der
> >> Basisadressen vorliegt, wird wieder gemauert was das Zeug h??lt, und
> >> auch noch im GitHub Forum suggestiv geflennt.
> >> 
> >> Das ist doch alles nur noch peinlich. Es wird keine Verbesserung in
> >> der OSM Adress Situation gewollt. Und der Ober Guru dieser Aktion ist
> >> auch noch Kassier im osm Verein AT.
> >> Mein Misstrauensantrag an diesen.
> >> 
> >> Gre Johann
> >> Osm: wiki the map
> >> 
> >>> Am 22.02.2018 um 00:09 schrieb Rudolf Mayer :
> >>> 
> >>> Hallo!
> >>> 
> >>> Sorry f??r den Vollquottel unten, aber Andreas, du sprichst mir hier aus 
> >>> der Seele mit deiner Antwort.
> >>> 
> >>> 
> >>> @Johann, ich verstehe nicht, was genau Deine Motivation ist. Du 
> >>> unterstellst allen anderen, dass sie keine besseren Daten haben wollen.
> >>> 
> >>> Und was machst du - du f??gst unn??tige Duplikate ein (und ja, es
> >>> ist gut dass Deine 20.000 Adressen gel??scht wurden, da war vorher
> >>> von Dir keinerlei Kontrolle was du ??berschreibst / duplizierst, so
> >>> geht das einfach nicht), nur damit *eine* Anwendung, ??ber welche
> >>> die Entwickler selber sagen, dass sie kaputt ist, irgendwie
> >>> funktioniert? Das kann es ja wirklich nicht sein, so stur, das ist
> >>> schon surreal.
> >>> 
> >>> Deine Nachrichten sind teilweise sehr m??hsam zu lesen. Z.B. wenn Du
> >>> da proklamierst, das "Adressr??tsel" gel??st zu haben (wenn du aber
> >>> nur best??tigt hast, was dir andere (z.b. fkv) schon mehrmals gesagt
> >>> haben; wenn Du dauernd das selbe wiederholst und einen bestimmten
> >>> Hack in den Daten machen willst, obwohl Dir genug Kollegen
> >>> widersprechen, etc. Wenn du jeden beschuldigst, ein Feind von guten
> >>> Daten zu sein...
> >>> 
> >>> Und ich habe da von Dir auch keinerlei Vorschlag gesehen, wie ein
> >>> zuk??nftiger Import das besser machen w??rde, wie du Duplikate
> >>> filtern oder bereinigen willst.
> >>> 
> >>> Ich w??rde vorschlagen, ??ber das mal zu reflektieren, und nicht
> >>> gleich anzunehmen, dass hier die "b??se Wiener Gang" einen
> >>> schlechten Datenbestand verteidigen will..
> >>> Ich bin selber 1/4 Tiroler, 3/4 Steirer, aber nun mal grtenteils
> >>> in Wien unterwegs, und ich h??tte bis jetzt nicht das Gef??hl
> >>> gehabt, dass da eine generelle Abneigung zu Mappern, die nicht nur
> >>> Wiener Blut haben, gibt :-) Ich glaube, das liegt eher an deinem
> >>> unausgereiftem Vorschlag und gro??em Import, der vorher einfach
> >>> nicht diskutiert wurde. Und darauf hast du dann eigentlich nur
> >>> patzig reagiert, anstatt einen Fehler in der Vorgehensweise
> >>> einzusehen, und das in Ruhe zu diskutieren.
> >>> 
> >>> Also, bitte, ein paar mal tief durchatmen, und nicht gleich in den
> >>> Berserkermodus wechseln.
> >>> 
> >>> Lg
> >>> Rudi
> >>> 
> >>> 
> >>> P.s.: 

Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[majka]

>
>
> Jinak díky za postřehy, všechno je to stále ve vývoji. Bylo by super,
> kdyby sis našel trochu času a upravil popis na TaskManageru, aby to bylo
> pro nováčky srozumitelnější.
>

Nahodila jsem trochu dokumentace k tomu, co ukazuje ohledně schránek
POI-importer a co se pak od člověka čeká. Je to opravdu jen první
nekompletní nástřel, ale třeba někomu pomůže.
Odkaz je vložený do instrukcí taskmanu, ale pro jistotu i sem
 .

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

Re: [Talk-it] Di nuovo l'utente pasticcione

[Cascafico Giovanni]

e' importante fare ad ogni changeset un breve commento chiaro in inglesem
meglio se da più utenti, dopodochè si segnala al Data Working Group con una
mail. Di solito intervengono in 24h con un blocco breve, giusto perchè
l'utente pasticcione legga che altri stanno segnalando il comportamento
scorretto.

Il giorno 22 febbraio 2018 18:22, Andreas Lattmann  ha scritto:

> Si, qualcosa del genere, perché se no ci scappa la situzione dalle mani.
> Segnalo un utente a Napoli che fa changeset cambiando buildings in parchi
> ed altri scempi. L'utente è https://www.openstreetmap.org/
> user/Mauro%20Lepore da come risulta da questi commenti al changeset:
> http://www.openstreetmap.org/changeset/56578763#map=11/40.8728/14.2554
>
> Un po in tutta Italia stanno avvenendo questi atti vandalici.
>
> Andreas Lattmann
> --
> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[Martin Koppenhoefer]

sent from a phone

> On 22. Feb 2018, at 15:48, Simone Saviolo  wrote:
> 
> ricevuto un volantino pubblicitario (a proposito, quelli sono coperti da 
> copyright?),


si, sono coperti da copyright ma non c’entra niente, perché i fatti non sono 
mai protetti da copyright, solo le creazioni nuovi di ingenuo (es. volantino: 
la grafica, la composizione ecc.)


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

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[Martin Koppenhoefer]

sent from a phone

> On 22. Feb 2018, at 15:09, emmexx  wrote:
> 
> Ma nessuno ha mai provato a chiederlo direttamente a Google? ;-)


si, hanno chiesto ma mai ricevuto risposta (credo)


Ciao, Martin 

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

Re: [Talk-us] Rural US: Correcting Original TIGER Imported Ways

[ajt1...@gmail.com]

On 22/02/2018 16:57, Greg Troxel wrote:

For the US, however, you'd want to do something other than just
"downgrading to track".  There are a couple of options I suspect:

In the US, treating an unpaved road as "track" does not seem right.
Besides the surface issue, there is a very strong notion of legal status
between a "road" (often on its own parcel, traffic laws apply)and a
"track" (just a place where you could drive within some larger lot, and
often considered that traffic laws do not apply).

It also seems to me that the typical rendering of track is heavier and
more visually prominent than highway=residential, where for a
general-use map it seems that tracks are lesser ways.


One is to split unpaved roads out as a separate "road type" altogether
(that's how sidewalk and verge are handled as seen at
https://map.atownsend.org.uk/maps/map/map.html#zoom=15=-24.99273=135.02137
).  The other is to have some sort of modifier (like "bridge", but
different).  that's how "long fords" and embankments at
https://map.atownsend.org.uk/maps/map/map.html#zoom=15=-24.99958=135.0693
are handled.

I suspect I'm failing to understand something, but it seems that

   highway=residential surface=paved (or no tag, default)
   highway=residential surface=unpaved

should have rendering that is similar in weight, but with some clue that
one is not paved.


Indeed (hence why I wrote 'For the US, however, you'd want to do 
something other than just "downgrading to track"' above).  The "One is 
to split..." comment is about technically how to do it within an OSM 
Carto-like style; I'm not trying to suggest how things should look,



Dashed casing seems plausible.  But I realize this is
very hard as we try to represent more and more in a single map.
A dashed casing's certainly technically doable (though I suspect you'd 
need to fiddle with widths of things to get the visual weight right).  
You may to show tunnels (which use a very fine dashed casing - see e.g. 
https://www.openstreetmap.org/#map=15/51.5046/-0.0500 ) in a different 
way though first.


Best Regards,
Andy


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

Re: [Talk-it] Di nuovo l'utente pasticcione

[Andreas Lattmann]

Si, qualcosa del genere, perché se no ci scappa la situzione dalle mani. 
Segnalo un utente a Napoli che fa changeset cambiando buildings in parchi ed 
altri scempi. L'utente è https://www.openstreetmap.org/user/Mauro%20Lepore da 
come risulta da questi commenti al changeset: 
http://www.openstreetmap.org/changeset/56578763#map=11/40.8728/14.2554

Un po in tutta Italia stanno avvenendo questi atti vandalici.

Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[Martin Koppenhoefer]

sent from a phone

> On 22. Feb 2018, at 13:02, emmexx  wrote:
> 
> I casi in cui Google vincerebbe facilmente una causa sono abbastanza
> ovvi. Ed è cosa nota che nelle mappe (o nei dizionari) vengano inseriti
> di proposito elementi errati in attesa che qualcuno li copi.


oppure il mappatore dichiara pubblicamente di aver preso informazioni da 
google...


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

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[Martin Koppenhoefer]

sent from a phone

> On 22. Feb 2018, at 12:18, Cascafico Giovanni  wrote:
> 
> Vabbe', allora avvertite il DWG che c'è un utente che dev'essere bloccato.. 
> andrò a far compagnia al vandalo di Trieste.


no, il caso è diverso del vandalo, nel caso di infrazione di diritti di terzi 
devono fare una “redaction”

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

Re: [Talk-it] Di nuovo l'utente pasticcione

[Cascafico Giovanni]

Per cominciare c'è la lista degli user blocks è1] che contiene i blocchi in
fase di termine, ma anche i blocchi terminati (quindi a rischio di
recidivi). Poi che un warning in osmcha tipo "User has multiple blocks",
per esempio per il vandalo di Trieste [2].


[1] https://www.openstreetmap.org/user_blocks?page=3
[2]
https://osmcha.mapbox.com/?filters=%7B%22users%22%3A%5B%7B%22label%22%3A%22Roberto%20Dipiazza%22%2C%22value%22%3A%22Roberto%20Dipiazza%22%7D%5D%7D


Il giorno 22 febbraio 2018 16:45, Marco  ha scritto:

> Il 17/02/2018 21:35, Andreas Lattmann ha scritto:
>
> Altri suggerimenti per strumenti utili a monitorare utenti sospetti??
>>
>> Andreas Lattmann
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>
>
>
> A che sito/servizio potremmo appoggiarci per fare un lista nera degli
> utenti da tenere sotto controllo?
> Sto pensando a qualcosa simile ad un foglio excell, pubblico o comunque
> accessibile e modificabile da più mappatori
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] leisure=pitch come inner?

[Martin Koppenhoefer]

sent from a phone

> On 22. Feb 2018, at 15:39, demon.box  wrote:
> 
> ciao, se trovo già mappata un'area molto estesa come multipoligono
> landuse=residential e sopra questa vado a mappare alcune aree leisure=pitch
> devo metterle come membri con ruolo inner?


io favorisco la mappatura dettagliata per i landuse. Quando trovo dei 
multipoligoni molto grandi e ci tengo alla zona mi impegno a spezzare il 
poligono in tanti più piccoli (tolgo le strade, che non sono 
landuse=residential, per esempio). Così si crea una base molto più facilmente 
gestibile e trasparente (facile da capire), e anche più precisa (scala più 
dettagliata). Poi quel pitch raramente si trova su una particella residenziale, 
e quindi non lo includerei nel landuse=residential (in certi casi anche sì 
invece, es. campo da tennis nel giardino della villa).

Volendo e in certi casi potrebbe avere senso addirittura di andare ancora sotto 
la scala della particella (sub-aree), ma li vedo come eccezione 
(laboratorio/ufficina e residenza sulla stessa particella, per esempio)


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

Re: [Talk-us] Rural US: Correcting Original TIGER Imported Ways

[Greg Troxel]

> For the US, however, you'd want to do something other than just
> "downgrading to track".  There are a couple of options I suspect:

In the US, treating an unpaved road as "track" does not seem right.
Besides the surface issue, there is a very strong notion of legal status
between a "road" (often on its own parcel, traffic laws apply)and a
"track" (just a place where you could drive within some larger lot, and
often considered that traffic laws do not apply).

It also seems to me that the typical rendering of track is heavier and
more visually prominent than highway=residential, where for a
general-use map it seems that tracks are lesser ways.

> One is to split unpaved roads out as a separate "road type" altogether
> (that's how sidewalk and verge are handled as seen at
> https://map.atownsend.org.uk/maps/map/map.html#zoom=15=-24.99273=135.02137
> ).  The other is to have some sort of modifier (like "bridge", but
> different).  that's how "long fords" and embankments at
> https://map.atownsend.org.uk/maps/map/map.html#zoom=15=-24.99958=135.0693
> are handled.

I suspect I'm failing to understand something, but it seems that

  highway=residential surface=paved (or no tag, default)
  highway=residential surface=unpaved

should have rendering that is similar in weight, but with some clue that
one is not paved.  Dashed casing seems plausible.  But I realize this is
very hard as we try to represent more and more in a single map.  I
cannot quibble with your advice to actually try something...




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

Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[Marián Kyral]

Ahoj,

Dne 22.2.2018 v 13:11 Petr Vozdecký napsal(a):
>
> Pises "do statistik". Bylo by asi efektivnejsi generovat "rozdilovy
> soubor", tedy v tomto pripade seznam schranek, ktere jsou v OSM a
> ktere nejsou zatim naparovany. Tyto zobrazovat v POI importeru jako
> samostatnou vrstvu. Tim bych totiz asi jako mapper zacal, protoze mam
> vetsi duveru v geografickou presnost techto dat... A k temto datum
> bych v prvni rade dohledaval "zatolulane" schranky z dat CP...
>

Tak teoreticky to implementovatelné je, ale jde to proti filozofii
POI-Importeru. (Nejsem autorem, jen jsem jej trochu přiohnul).
Pokud tě to zajímá, můžeš si nepropojené schránky najít přes
overpass-turbo: http://overpass-turbo.eu/s/wpU
Ale pokud je tam nějaká rozumná vzdálenost, POI-Importer by tu schránku
měl vidět. Pokud není, tak ti to stejně moc nepomůže. Leda podle popisu
a to už by ta schránka měla být v mapě vidět.

Zdrojová data od české pošty jsou v zákaznických výstupech:
https://github.com/mkyral/osm/tree/master/import/ceska_posta#dataset
Je to "normální" csv.

60010;Depo Brno 71;780Masarykova, obch.dům, Zbýšov u
Brna;Zbýšov;Zbýšov;Brno-venkov;10:00;1-5 - pracovní dny (pondělí až pátek)
60010;Depo Brno 71;1;Masarykova 248, 66411,
Zbýšov;1163194.13;617397.31;pošta Zbýšov u Brna12:00;1-5 - pracovní
dny (pondělí až pátek)


Když máme štěstí, tak tam jsou souřadnice (křovák), většinou vedoucí na
souřadnice daného adresního bodu. Takže když je schránka před objektem,
souřadnice ukazují někam doprostřed objektu.
Když nemáme štěstí, tak tam souřadnice nejsou a je tam jen popis typu
"Horní Dolní, u obchodu". Tyhle schránky se v POI-Importeru vůbec
neobjevily - neměly souřadnice. Takže je Majka prošla, upravila ty
popisy do nějaké jednotné formy a pomocí skriptu se pokusila dohledat
správné souřadnice. Což se ne vždy povedlo. Proto je tam taky to krásné
*ČERVENÉ* varování :-D

Jinak díky za postřehy, všechno je to stále ve vývoji. Bylo by super,
kdyby sis našel trochu času a upravil popis na TaskManageru, aby to bylo
pro nováčky srozumitelnější.


BTW:
ty nepropojené schránky stejně brzy dojdou (pak už budou jen takové ty
výdejní boxy)




Marián


>
> -- Původní e-mail --
> Od: Marián Kyral 
>
> - (jednosměrnost) v POI importeru vidím vizualizované jen ty
> schránky, které jsou v externí datové sadě České pošty? Tedy
> pokud oni něco nemají a my ano, je to nějak vizualizováno?
>
>
> Ano. POI-Importer funguje tak, že externí data jsou správně.
> Vizualizaci dat, která v datasetu nejsou neumí (a asi by bylo
> trochu komplikované to tam dopsat).
>
> Nicméně plánuji přidat do statistik stránku s přehledem
> nespárovaných schránek (jsou v OSM, ale nemají ref, nebo mají
> jiného operátora).
>
>
>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

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

[Talk-es] Maps, app libre en F-Droid basada en MAPS.ME

[Iván Hernández Cazorla]

Buenas,
Creo que el título lo dice todo. Me gustaría compartir con ustedes una 
aplicación que encontré hoy en F-Droid [0] y que fue publicada hace solo 
dos días. Se trata de Maps [1] y está basada en MAPS.ME [2], un servicio 
que se que muchos de ustedes también usan. Puede que les guste, ya que 
se trata de una versión más acorde a los principios de los proyectos en 
los que trabajamos, al menos desde mi punto de vista claro.


Yo suelo utilizar OsmAnd, también en F-Droid [3]. Pero quise probar esta 
para y comprobar qué tal funciona. De momento me he descargado el mapa 
mundi general, necesario para la app, y el mapa de Canarias, y parece 
que funciona bastante bien.


Lo dicho, se las dejo por si la quieren probar. Sobre todo para Miguel, 
que sé que, aunque creo que prefiere OsmAnd, seguro querrá probarla al 
ser una app FOSS [4].


Saludos,
Iván

[0]: repositorio de aplicaciones libres y de código abierto para 
Android: https://f-droid.org/en/about/

[1]: https://f-droid.org/packages/com.github.axet.maps/
[2]: https://maps.me/
[3]: https://f-droid.org/packages/net.osmand.plus/
[4]: https://es.wikipedia.org/wiki/Software_libre_y_de_c%C3%B3digo_abierto
--
Iván Hernández Cazorla
Miembro de Wikimedia España

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

[Talk-lv] neasfaltētu ceļu attēlošana osm.org

[Rihards]

Diskusija ir atsākusies, ir daži piedāvājumi - pie tam, ar Latvijas
datiem :)

https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-367668091
-- 
 Rihards

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

Re: [OSM-talk-fr] Zones géographiques informelles

[Sylvain M]

Je me suis récemment posé cette question sur un massif forestier [1].
Après avoir tenté de le représenter en fusionnant les chemins des
landuse=forest, j'ai abandonné car en fait, la limite n'est pas vraiment
précise (floue on peut dire).

A y réfléchir, ce qui me semblerait le plus pertinent, c'est un nœud avec la
clé "place=".

Par exemple, dans mon cas, "place=forest"

Il y a bien des "place" qui pourraient s'apparenter à des zones naturelles
[2] (place=island ou place=islet)

L'intérêt, ensuite, c'est que les moteurs de recherche (nominatim, ...)
trouvent le lieu, et que l'on peut y attribuer des tags complémentaires,
comme wikipedia/wikidata quand ces pages existent.

Sylvain M.

[1] https://forum.openstreetmap.fr/viewtopic.php?t=6676
[2] https://taginfo.openstreetmap.org/keys/place#values




--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [Talk-us] Rural US: Correcting Original TIGER Imported Ways

[Paul Johnson]

On Feb 21, 2018 23:29, "Nick Hocking"  wrote:

I've always been of the opinion that any of the original TIGER data import
that has not yet been edited and does not have a name tag, should just be
deleted.

Then, and only then can the rural areas begin to be mapped correctly.

In the early days there were  a lot of people who thought that "any data is
better than no data" whereas I believe that "no data" is better than bad
data.

Or maybe the unedited original TIGER that's still around dropped to
highway=road.  Arguably this should have been the default to start with as
"we think there's a road here but not sure exactly what" type thing anyway.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] leisure=pitch come inner?

[Andrea Albani]

Il giorno 22 febbraio 2018 17:17, Federico Cortese 
ha scritto:

>
> Secondo me no, non sono in conflitto con landuse, tantomeno se
> residential, quindi non devono essere escluse.
>

+1

Descrivono cose logicamente diverse.

Un campo da tennis ad esempio può stare all'interno di un'area
residenziale, così come ci possono stare i building, etc.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] leisure=pitch come inner?

[Federico Cortese]

2018-02-22 15:39 GMT+01:00 demon.box :
> ciao, se trovo già mappata un'area molto estesa come multipoligono
> landuse=residential e sopra questa vado a mappare alcune aree leisure=pitch
> devo metterle come membri con ruolo inner?

Secondo me no, non sono in conflitto con landuse, tantomeno se
residential, quindi non devono essere escluse.

Ciao,
Federico

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

Re: [OSM-talk-fr] JOSM transfert des nœuds et pas des chemins

[marc marc]

Bonjour,

Le 22. 02. 18 à 16:48, Rpnpif a écrit :
> Je suis novice dans JOSM.
> https://www.openstreetmap.org/changeset/56579562
> Qu'en pensez-vous ?

Pour un premier changeset avec un nouvel éditeur,
je pense que tu as fais une modif trop gigantesque.
1 nœuds c'est la limite maxi pour un changeset

as-tu toujours ta modif dans josm ? si oui cela serra utile
pour comprendre car il peux y avoir plusieurs causes :
- soit c'est la limite des 1 qui t'a bloqué mais josm sait
qu'il y a encore des choses à envoyer. fait un test d'envois
sans envoyer (=annule avant l'envoi), cela te dira ce qu'il en est.
- tu peux aussi sélectionner un chemin et faire "menu fichier,
envoyer la sélection", cela te dira si josm considère qu'il faut 
l'envoyer ou pas.

Mais autres questions :
- comment as-tu fait pour utiliser le site web renseigné en source
pour créer des objets dans josm ?
si c'est un simple download de leur donnée et envoi dans osm, cela veu 
dire qu'il y a des doublons avec tout ce qui existe deja dans osm
- si c'est un import (=prendre des données externes pour les ajoutées 
dans osm), il aurait du être discuté
- il n'est pas nécessaire et même contre productif de mettre un source 
sur tous les objets
- source contient le nom de la source, pas l'url (qui va éventuellement 
dans source:url mais peu utilisé)

J'annule et on repart de 0 ? :-)

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

Re: [Talk-es] Opensouthcode 2018

[David Sedeño]

Aunque el plazo del CfP ha terminado, aún no está realizado el programa, 
así que que contactad conmigo si alguien se anima a presentar el 
proyecto en la conferencia, estaría genial :)


Saludos

David Sedeño



El 21/02/18 a las 09:25, Miguel Sevilla-Callejo escribió:

Pues siendo en Málaga yo animaría a Daniel Capilla a que fuera.

No tiene ni por qué preparar material sobre el tema, que reutilice 
parte del material que hay en el repositorio de presentaciones:

http://bit.ly/osmpresentaciones

Saludos



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

2018-02-21 1:07 GMT+01:00 Alejandro S. >:


Buenos días,

Hago bump de esto porque creo que sería interesante que se diera
una charlica de difusión de OpenStreetMap. ¿Ningún contribuidor de
la zona se atreve/quiere? Si hay ganas igual se podría hacer
incluso una mapping party.

Yo daría la charla, pero me cae un poco mal ir desde Zaragoza sólo
para dar la charla...

Saludos,
Alejandro Suárez


On Wed, Feb 7, 2018, 18:43 David Sedeño > wrote:

Hola,

tenemos abierto el plazo de recepción de actividades para la
tercera
edición de Opensouthcode, que se realizará en Málaga el 1 y 2
de junio.

Opensouthcode es un evento dedicado al software/hardware libre y
tecnologías abiertas. Nos encantaría que puedierais dar a
conocer el
proyecto Openstreetmap dentro del evento.

Más info: https://www.opensouthcode.org

Gracias y saludos
---
David Sedeño


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



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





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


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

Re: [OSM-talk-fr] JOSM transfert des nœuds et pas des chemins

[Francescu GAROBY]

Bonjour,
Je ne sais pas si le problème vient de JOSM qui a foiré l'upload, mais je
note que ton changeset n'a que des nodes. Aucune way n'a été uploadée !

Francescu

Le 22 février 2018 à 16:48, Rpnpif  a écrit :

> Bonjour,
>
> Je suis novice dans JOSM.
> J'ai voulu importer des ruisseaux manquants sur une petite zone à titre
> d'essai en veillant bien à ne pas écraser ceux existants et à partir de
> la base nationale du Ministère de l'environnement.
>
> J'avais bien la vision des waterway=stream sur tous les ways sous JOSM.
> Tout était correct.
> Mais dans OSM, je n'obtiens que les nœuds sans aucun way. Ils sont
> « secs » sans attributs autres que la source.
>
> D'après vous, ai-je fait une fausse manipulation, oublié quelque chose
> ou c'est un problème de JOSM (dernière version) ?
>
> Je précise que JOSM a planté à un autre moment après un redémarrage
> après mise en veille de mon système et pour lequel j'ai fait un ticket.
> Je doute quand même qu'il y ait un lien.
>
> Le changeset est ici ;
> https://www.openstreetmap.org/changeset/56579562
>
> Qu'en pensez-vous ?
> --
> Alain Rpnpif
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[Simone Saviolo]

Il giorno 22 febbraio 2018 16:45, Volker Schmidt  ha
scritto:

> Scusate,
>
> mi sembra che mescoliamo due argomenti
> *i fatti: *
> Io ho copiato più o meno da una fonte Google, StreetView in questo caso
> *le prove che l'ho fatto: *
> come Google potrebbe dimostrare senza dubbi che io ho copiato da Google
>

Beh, no. Io sto dicendo che anche senza copiare da Street View qualcuno
potrebbe sostenere ragionevolmente che ho copiato da Street View. E che io
farei fatica a confutare la sua tesi.

Oppure, in alternativa, che né la sua tesi né la mia hanno alcun fondamento
logico, e che si deciderà sulla base di qualcos'altro.

Il mio punto è che non dobbiamo copiare per non mettere a rischio il
> progetto.
>

D'accordissimo. Ma definisci "copiare".

Tutta questa discussione è un po' come:
> C'è un cartello di limite di velocità di 50km/h.
> Uno dice: "Devo andare non più veloce di 50km/h"
> e l'altro risponde
> "Perché? La polizia non può provare che sei andato più veloce, non c'è un
> autovelox in quel posto!"
>
> (so che semplifico, ma gli argomenti della discussione sono su piani
> disgiunti)
>

Sì, semplifichi. La velocità è un dato misurabile. La misura ha un margine
di incertezza, e di quello si tiene conto, e con questo sono finiti i
problemi. Un paragone migliore sarebbe quello del "moderare la velocità":
in prossimità di un incrocio devo "moderare la velocità"... ma moderarla
quanto? Ho rallentato abbastanza? Ero veramente in prossimità di un
incrocio, anche se io ero su una statale in aperta campagna e da sinistra
arrivava un tratturo privato usato solo dai trattori?

Ciao,

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

[OSM-talk-fr] JOSM transfert des nœuds et pas des chemins

[Rpnpif]

Bonjour,

Je suis novice dans JOSM.
J'ai voulu importer des ruisseaux manquants sur une petite zone à titre
d'essai en veillant bien à ne pas écraser ceux existants et à partir de
la base nationale du Ministère de l'environnement.

J'avais bien la vision des waterway=stream sur tous les ways sous JOSM.
Tout était correct.
Mais dans OSM, je n'obtiens que les nœuds sans aucun way. Ils sont 
« secs » sans attributs autres que la source.

D'après vous, ai-je fait une fausse manipulation, oublié quelque chose
ou c'est un problème de JOSM (dernière version) ?

Je précise que JOSM a planté à un autre moment après un redémarrage
après mise en veille de mon système et pour lequel j'ai fait un ticket.
Je doute quand même qu'il y ait un lien.

Le changeset est ici ;
https://www.openstreetmap.org/changeset/56579562

Qu'en pensez-vous ?
-- 
Alain Rpnpif

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

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[Simone Saviolo]

Il giorno 22 febbraio 2018 16:34, emmexx  ha scritto:

> On 02/22/2018 03:48 PM, Simone Saviolo wrote:
>
> > Chi può stabilire da dove viene la mia conoscenza?
>
> Un giudice?
>

Mi legge nel cervello? Anzi, nella cronologia del mio cervello :)


> > Ripeto: ok la protezione sui database, ok le opere derivate, ma una
> > licenza sui dati fattuali è assurda (nel senso di indefinibile e
> > inapplicabile).
>
> Alberto Nogaro ha postato il link ad una risposta di Google sulla
> questione. Lì mi pare ci sia tutto ciò che serve sapere.
>

È una risposta di sette anni fa, data da uno che non mi sembra sia un
avvocato, e che dice "ma, forse che sì, un po', probabilmente che no".

A me pare che in questa lista si debba chiarire che StreetView non è uno
> strumento da usare, se possibile, o da usare con moltissima moderazione.
> Se lo si usa per mappare le strade di un intero comune o tutti gli
> alberi di una via, la violazione della licenza è plateale e palese e
> deve essere chiaro che questo non va fatto.


Sei già in disaccordo con quasi tutti. Hai creato una posizione nuova: "da
usare con moltissima moderazione" - ma tu stesso sembri vago su questa
posizione.

Se devo riassumere tutto questo lungo thread, con spunti molto
interessanti, posso usare una sola parola: "inconcludente". Mi ricorda la
discussione sul GPDR e su tutti i regolamenti che l'hanno preceduto:
"sembrerebbe che sia così - però bisognerà vedere cosa sentenzieranno i
giudici la prima volta che qualcuno verrà processato".

Secondo me, la verità è che la licenza non può determinare cosa si può fare
e cosa no senza alcuna zona grigia, e che quando qualcuno andrà in
tribunale ci saranno decine di fattori estemporanei che porteranno ad una
decisione piuttosto che ad un'altra. E noi continueremo a chiederci cosa si
può fare - e continueremo a non saperlo.

Ciao,

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

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[Volker Schmidt]

Scusate,

mi sembra che mescoliamo due argomenti
*i fatti: *
Io ho copiato più o meno da una fonte Google, StreetView in questo caso
*le prove che l'ho fatto: *
come Google potrebbe dimostrare senza dubbi che io ho copiato da Google

Il mio punto è che non dobbiamo copiare per non mettere a rischio il
progetto.

Tutta questa discussione è un po' come:
C'è un cartello di limite di velocità di 50km/h.
Uno dice: "Devo andare non più veloce di 50km/h"
e l'altro risponde
"Perché? La polizia non può provare che sei andato più veloce, non c'è un
autovelox in quel posto!"

(so che semplifico, ma gli argomenti della discussione sono su piani
disgiunti)
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Di nuovo l'utente pasticcione

[Marco]

Il 17/02/2018 21:35, Andreas Lattmann ha scritto:


Altri suggerimenti per strumenti utili a monitorare utenti sospetti??

Andreas Lattmann

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




A che sito/servizio potremmo appoggiarci per fare un lista nera degli 
utenti da tenere sotto controllo?
Sto pensando a qualcosa simile ad un foglio excell, pubblico o comunque 
accessibile e modificabile da più mappatori


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

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[emmexx]

On 02/22/2018 03:48 PM, Simone Saviolo wrote:

> Chi può stabilire da dove viene la mia conoscenza?

Un giudice?

> Ripeto: ok la protezione sui database, ok le opere derivate, ma una
> licenza sui dati fattuali è assurda (nel senso di indefinibile e
> inapplicabile). 

Alberto Nogaro ha postato il link ad una risposta di Google sulla
questione. Lì mi pare ci sia tutto ciò che serve sapere.

A me pare che in questa lista si debba chiarire che StreetView non è uno
strumento da usare, se possibile, o da usare con moltissima moderazione.
Se lo si usa per mappare le strade di un intero comune o tutti gli
alberi di una via, la violazione della licenza è plateale e palese e
deve essere chiaro che questo non va fatto.

ciao
maxx

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[djakk djakk]

Hello,

I totally agree with you, the definition you provide, administrative-free,
tends to the same osm map between countries.

djakk

Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien 
a écrit :

> Landing on this discussion several months late. I've just heard of it
> by reading a wiki talk page [1].
>
> Since 13 February 2009, the wiki [2] criticises highway classification
> as problematic/unverifiable. This has also been subject to a lot of
> controversy (and edit wars) in my local community (Brazil), especially
> regarding the effect of (lack of) pavement.
>
> In trying to achieve greater consensus some years ago, I decided to
> seek opinions elsewhere and finally I arrived at this scheme [3] which
> I think is very useful, if not perfect yet. It can be easily
> summarised like this:
> - trunk: best routes between large/important cities
> - primary: best routes between cities and above
> - secondary: best routes between towns/suburbs and above
> - tertiary: best routes between villages/neighbourhoods and above
> - unclassified: best routes between other place=* and above
>
> For example, the best route between two villages would be at least
> tertiary. So would be the best route between a village and a town or a
> city. Parts of this route might have a higher class in case they are
> part of a route between more important places.
>
> It surely raises the problem of determining optimal routes. Maybe a
> sensible criterion would be average travel time without traffic
> congestion. A number of vehicles may be selected for this average -
> could be motorcycle+car+bus+truck, or simply car+truck.
>
> Early results in my area [4, in Portuguese] seem promising and have
> produced more consensus than any previous proposals. To me, this
> method seems to:
> - resist alternations in classification along the same road
> - work across borders (where classification discontinuities are
> expected because each country is using different classification
> criteria)
> - account for road network topology
> - work in countries with mostly precarious/unpaved roads or
> without/unknown official highway classes
> - work between settlements as well as within settlements
>
> Borderline cases are probably inescapable in any system that does not
> use solely criteria that are directly verifiable - from the ground, or
> from the law. Maybe, in certain developed countries, the system is so
> well organized that merely checking signs/laws is sufficient. That
> does not mean it is like that everywhere on the planet.
>
> OSM has so far received a lot of input from communities in developed
> countries (mostly Europe, North America and Australia) and hasn't
> given much attention to less developed/organized countries. What comes
> closest to this is what the HOT Team does, but the judgment of road
> classification one can do from satellite images in a foreign country
> is much more limited than the criteria that have been raised in this
> thread so far.
>
> I wouldn't endorse tags such as maxspeed:practical due to lack of
> verifiability (it should be obvious that different types of vehicles
> would achieve different practical speeds). It is better to use the
> legal speed in maxspeed=* and describe the practical reason for a
> lower speed using surface=*, smoothness=*, and, who knows, maybe the
> not yet approved hazard=* [5] (though that is intended for signed
> hazards, not subjective/opinionated hazards).
>
> For the sake of long-term sanity, I also wouldn't mix the purpose of
> one tag with the purpose of other tags. To describe the surface, there
> is surface=*, smoothness=* and tracktype=*. To describe access rights,
> there is access=*, foot=*, bicycle=*, motor_vehicle=*, etc. To
> describe legal speed, maxspeed=*. To describe curves, there's
> geometry.
>
> Purpose, perhaps, is the main issue. What is the purpose of highway
> classification? Is it to save us the work of adding extra tags? Is it
> to allow the renderer to produce a cleaner output at low zoom levels?
> Is it to allow routers to assume default speeds? Maybe to guide their
> routing heuristics? Is it to express some sort of importance? If so,
> by which perspective - urbanistic, traffic engineering, movement,
> commercial value, cultural/fame, historic, some combination of those?
> Should the purpose be the same in every country?
>
> It may be interesting to also discuss the classification adopted by
> other maps. I don't have a reference for Google (originally TeleAtlas)
> or Here.com (originally Navteq), but Waze publishes its per-country
> road classification criteria in its wiki. [6-16]
>
> [1]
> https://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dtrunk#change_.22high_performance.22_to_.22high_importance.22
> [2] https://wiki.openstreetmap.org/wiki/Verifiability#Problematic_tags
> [3]
> https://wiki.openstreetmap.org/wiki/User:Ftrebien/Drafts/Generic_highway_classification_principles#Schematic_diagram_and_general_comments
> [4] 

Re: [OSM-talk] The diversity-talk@ list is back! [WAS: Re: diversity-talk: No such list]

[Sérgio V .]

Hi, glad to know this, this is an important topic in OSM ecosystem, as well as 
in the world, mainly nowadays. Signed, thanks! From Brazil,

- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Rory McCann 
Enviado: quinta-feira, 22 de fevereiro de 2018 05:36
Para: Sérgio V.; talk@openstreetmap.org
Assunto: The diversity-talk@ list is back! [WAS: Re: diversity-talk: No such 
list]

Hello all,

I've volunteered to do the admin/modding of the diversity-talk list, so
it has been set up again.

You need to sign up again for now. Maybe it's possible to import an old
membership list, but for now, please re-sign up.

 https://lists.openstreetmap.org/listinfo/diversity-talk

Rory

On 17/02/18 20:56, Sérgio V. wrote:
> Hi, I've just realized that in the
>
> https://wiki.openstreetmap.org/wiki/Diversity
> at the bottom, /Resources,
>
> there's no such link to
>
> https://lists.openstreetmap.org/listinfo/diversity-talk
>
> If you click there , or search for it, it returns "No such list
> diversity-talk".
>
> Is it still alive?
>
>
> - - - - - - - - - - - - - - - -
>
> Sérgio - http://www.openstreetmap.org/user/smaprs
>
>
>
> ___
> 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] risposta a dichiarazione uso di GoogleStreetView

[Alberto Nogaro]

Tanto tempo fa era stato fatto:

https://lists.openstreetmap.org/pipermail/talk/2011-April/057473.html

Ciao,
Alberto

>-Original Message-
>From: emmexx [mailto:emm...@tiscalinet.it]
>Sent: giovedì 22 febbraio 2018 15:10
>To: openstreetmap list - italiano 
>Subject: Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView


>Ma nessuno ha mai provato a chiederlo direttamente a Google? ;-)



---
Questa email è stata esaminata alla ricerca di virus da AVG.
http://www.avg.com


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

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[Simone Saviolo]

Il giorno 22 febbraio 2018 15:09, emmexx  ha scritto:

> On 02/22/2018 02:43 PM, Simone Saviolo wrote:
> > Non ti sembra una prova? Allora descrivimi come dovrebbe essere una
> prova.
>
> La prova potrebbe esser la seguente:
> Nelle foto di StreetView la via Garibaldi appare il 20 settembre 2017,
> il 22 settembre 2017 la via Garibaldi appare anche in OSM.
> Ma anche in questo caso dovrebbero esserci altri elementi perché
> l'accusa tenga.
>

Metti pure che tramite la tecnologia magica riescano a sapere che avevo
JOSM aperto sulla zona che stavo guardando in Street View proprio un minuto
prima che committasi un changeset. Questo non dimostra niente: potrei
benissimo aver aperto Street View perché ho cercato su Google una
recensione della pasticceria che avevo visto due ore prima e che in quel
momento stavo aggiungendo su OSM.

Non si può dimostrare né l'innocenza né la colpevolezza. Perché la
pasticceria è fattuale. È lì, la vede chiunque. Come faccio a sapere che
esiste e come si chiama? Potrei averla vista di persona, potrei averla
sentita descrivere da un amico, potrei aver ricevuto un volantino
pubblicitario (a proposito, quelli sono coperti da copyright?), potrei
averla vista su Street View. Chi può stabilire da dove viene la mia
conoscenza?

> Strano come praticamente solo persone di origine straniera difendano
> una
> > certa posizione...
> >
> > Quello che interessa a me è dimostrare che una licenza su dati fattuali
> > è pressoché assurda per definizione. Infatti per farla rispettare si
> > introducono elementi fittizi... cioè non fattuali. Tra il dato fattuale
> > e una sua rappresentazione esiste una catena di comunicazioni (l'ho
> > saputo da X che l'ha saputo da Y che l'ha visto coi suoi occhi), ed è
> > pressoché impossibile ricostruirla correttamente. Inoltre, è sempre
> > possibile "assumere" (ma non dimostrare) che in quella catena ci sia
> > almeno un elemento che vieta la propagazione dell'informazione.
> >
>
> Quello che stanno dicendo alcuni è che, nel dubbio, anche uno solo,
> meglio non usare StreetView, meglio non scrivere che potrebbe essere
> lecito usarlo, meglio non far credere che sia possibile usarlo.
>
> Ma nessuno ha mai provato a chiederlo direttamente a Google? ;-)
>

Sì, e Google ha risposto (non lo trovo più) che non si può usare per
derivarne informazioni: la licenza lo vieta. (Dicevano anche che sarebbe
stato ingestibile perseguire le violazioni).

Street View non va usato per mappare. La definizione di "usato" è vaga. Per
i duri e puri, questo significa non aprire https://maps.google.com. Molti
dissentono. Bollarli come i soliti italiani è un'approssimazione del
problema: sicuramente a star lontani da Street View non si sbaglia, ma è
veramente necessario?

Mi immagino un'altra storiella. Prenoto una settimana in albergo al mare.
Voglio vedere bene quanto posto ho lì vicino per parcheggiare la macchina e
scaricare i bagagli. Allora vado su Street View e do un'occhiata: che
bello, proprio di fronte all'albergo c'è uno spiazzo di parcheggi gratuiti,
saranno una ventina, e nella foto del mese di luglio ce ne sono quattro
liberi, più uno per i disabili. Vado al mare, trovo posto lì, scarico i
bagagli e ci lascio la macchina per una settimana. Vedo quel parcheggio
tutti i giorni. Una sera, mentre sono sulla porta e aspetto di uscire, per
ingannare il tempo mi metto a contare i parcheggi: sono 17 più due per i
disabili. Forse nella foto di Street View uno era occupato... ah no, era
nascosto dalla cabina del telefono e non l'avevo visto.
Finisce la vacanza e torno a casa. Apro JOSM e segno la strada pedonale,
l'intitolazione della chiesa parrocchiale, la gelateria e il negozio di
scarpe: ci passavo davanti tutte le sere e le so a memoria. So che tra un
molo e un altro c'erano tre panchine, e le segno. Oltretutto ho fatto
tracce GPS per tutto il tempo, ho un sacco di note che ho preso col mio
telefono, tutta roba mia. Poi arrivo a quel parcheggio davanti all'albergo.
La prima volta che l'ho visto... l'ho visto su Street View. Potrò metterlo,
visto che non posso usare informazioni ricavate da Street View? Posso
scrivere che ci sono 17 posti più due per disabili? Io su SV non ci avevo
fatto caso, ma a guardare attentamente potrei ricavare quell'informazione
anche da lì.

Supponiamo invece che davanti all'albergo non ci siano posti, ma se giro a
destra e poi ancora a destra entro in un parcheggio che non si vede dalla
strada. Certo, ci sono andato, ho fatto avanti e indietro per prendere i
bagagli, l'ho visto di persona... ma se non l'avessi visto su Street View
non l'avrei mai scoperto. Posso aggiungerlo in quel caso?

Insomma, per essere al sicuro dal rischio di contaminare OSM, io mappatore
posso ancora fare uso di altri prodotti geografici commerciali? Non corro
forse il rischio di impararne qualcosa... che poi potrei mettere in OSM? :)

Ripeto: ok la protezione sui database, ok le opere derivate, ma una licenza
sui dati fattuali è assurda (nel 

[OSRM-talk] Questions on EdgeBasedGraph and NBGToEBG mapping

[Stephane Clinchant]

Hi,

 First of all, OS-RM is quite new for me, so the following may sound
as naive questions.

 I'd  like to dump some of the OS-RM graphs produced by the extractor to
benchmark

some code in python.


I could extract the node coordinates, the (Compressed)
Node Based Graph and the EdgeBasedGraph
.  However, I am bit confused by the NBGtoEBG mapping and how to use it.



An Edge in the EdgeBased Graph has the form

[edge_source,edge_target,duration,weight]

To get the ids of the corresponding nodes, then I should look in the
NBGToEBG mapping


to find
those edge ids. If that ids is found in the forward field, then I take
the node source id,

 else the target node id. Is that correct ? or is there a step I missed ?



So I tried that to plot some edges on a map from the node coordinates.

However, I found some nodes that are unlikely to be connected:

 it looks like something is wrong in what I did.



My second question is: If ‘x’ is an edge of the edge based edge graph,

in what units is x.data.duration and   x.data.weight ?



Thanks a lot,

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

[Talk-it] leisure=pitch come inner?

[demon.box]

ciao, se trovo già mappata un'area molto estesa come multipoligono
landuse=residential e sopra questa vado a mappare alcune aree leisure=pitch
devo metterle come membri con ruolo inner?
grazie
--enrico




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

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

Re: [OSM-talk-fr] conflit de précision de données a cause d'une clé

[Charles MILLET]

Merci pour les photos Francescu. J'ai fait aussi quelques photos 360 
dans le secteur et qui sont dans Mapillary. Je connais un peu le secteur 
pour y avoir fait quelquse cartoparties.


Clairement, même si le débat entre cycle=track et highway=cycleway est 
justifié dans bien des cas si l'on considère l'objectif de routage, dans 
la situation présente on penche très largement pour le second choix.


Au sujet du débat, je suis un peu gêné que le terme de "séparation 
physique", qui est déjà bien ambiguë se transforme en "obstacle entre 
les 2 qui empêche de passer de l'un à l'autre" qui l'est encore plus et 
qui va nous faire retomber dans les aspects réglementaires, les cas 
extrêmes, etc.


Je suis assez d'accord que pour le routage ça pose un problème mais je 
ne trouve pas que cela justifie une telle régression dans la précision 
de la description des aménagements. Pour utiliser très régulièrement des 
calculateurs d'itinéraire pour le vélo, j'ai toujours trouvé que ce 
phénomène était négligeable mais je comprends qu'on puisse exiger 
l'excellence d'OSM ;)


Sinon sur la page https://wiki.openstreetmap.org/wiki/FR:Bicycle il y a 
bien le "recommandé" et le reste.


Bref, je ne devrais pas dire ça mais bon voilà, je connais un peu le 
contributeur concerné et il y a peu de chance qu'il fasse un revert sur 
sa contribution pour le dire simplement. Donc pour répondre à la 
question initiale de David, je dirais qu'un /revert/ peut être justifier.


Bonne journée et bonne contribution à tous...

Charles MILLET
charlesmil...@free.fr

Le 21/02/2018 à 12:14, Francescu GAROBY a écrit :

Bonjour Axel (et les autres),
Ça tombe bien que tu demandes des photos, car je comptais dès hier 
soir vous en faire ce matin, vu que le Cours Montalivet est justement 
mon itinéraire quotidien à vélo. Les voici donc, hébergées sur framapic.
Pour commencer, il faut savoir qu'il n'existe aucun aménagement 
cyclable coté sud du Cours Montalivet : uniquement des contre-allées, 
ouvertes à tous, permettant de desservir les magasins qui s'y 
trouvent. Mon trajet se fait donc dans le sens ouest -> est, au nord 
du Cours (entre ce dernier et l'Orne).


* 1ère photo  
(prise ici 
 
dans le sens sud -> nord), la jonction entre le Cours et la piste 
cyclable se fait par un feu tricolore commun avec les piétons et, du 
fait des travaux actuels, il est même demandé aux cyclistes de 
traverser pied à terre.
* 2ème photo  
(prise ici 
), 
la piste est bidirectionnelle, et large (1m80, avec tout de même 
quelques rétrécissements, parfois dangereux, à certains endroits. Mais 
jamais moins de 1m de large). À noter aussi la bande de terre herbeuse 
et arborée, qui sépare la piste de la chaussée. Par endroit, le 
trottoir dépasse les 20cm de hauteur !
* 3ème  et 4ème 
 photos (prises 
ici 
 
et là 
) 
: pour comparaison, le Cours a lui aussi un terre-plein central 
herbeux et arboré. Puis uniquement herbeux et de la hauteur d'une 
petite motte de terre. Facilement franchissable par n'importe qui ! 
Même type de séparation, mais personne ne conteste la séparation 
physique des 2 axes de circulation.
* 5ème photo  : la 
piste a son propre revêtement. Il est séparé de la chaussée, pas 
refait au même moment, et même, par endroits, composé uniquement de 
plaques de béton, et non de bitume ! On voit d'ailleurs sur la photo 
qu'il a aussi son propre état : les racines des arbres soulèvent le 
bitume. Comme le Cours est plus souvent refait que la piste, ça ne se 
remarque que sur cette dernière...
* 6ème photo  
(prise ici 
) 
: cependant, les 20-30 derniers mètres de la piste, à l'approche de sa 
jonction avec le carrefour Cours Montalivet/Route de Cabourg, sont 
différents, en effet. Plus de séparation physique par un terre-plein. 
Là, qu'on dise que c'est du "track", pourquoi pas.


Bref, pour moi, il est clair qu'il s'agit d'une piste cyclable 
("highway=cycleway"), et non d'autre chose (mis à part les 20-30 
derniers mètres, à l'extrémité est). D'ailleurs (j'ai oublié de 
prendre une photo spécifique, pour ça), les jonctions entre le Cours 
et la piste sont inexistantes (mis à part aux extrémités et aux rares 
passages-piétons) ! Par exemple, il n'est pas possible d'aller des 
contre-allées coté sud du Cours, telle que l'allée du Bac, jusqu'à la 

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[emmexx]

On 02/22/2018 02:43 PM, Simone Saviolo wrote:
> Non ti sembra una prova? Allora descrivimi come dovrebbe essere una prova. 

La prova potrebbe esser la seguente:
Nelle foto di StreetView la via Garibaldi appare il 20 settembre 2017,
il 22 settembre 2017 la via Garibaldi appare anche in OSM.
Ma anche in questo caso dovrebbero esserci altri elementi perché
l'accusa tenga.

> 
> Strano come praticamente solo persone di origine straniera difendano una
> certa posizione...
> 
> Quello che interessa a me è dimostrare che una licenza su dati fattuali
> è pressoché assurda per definizione. Infatti per farla rispettare si
> introducono elementi fittizi... cioè non fattuali. Tra il dato fattuale
> e una sua rappresentazione esiste una catena di comunicazioni (l'ho
> saputo da X che l'ha saputo da Y che l'ha visto coi suoi occhi), ed è
> pressoché impossibile ricostruirla correttamente. Inoltre, è sempre
> possibile "assumere" (ma non dimostrare) che in quella catena ci sia
> almeno un elemento che vieta la propagazione dell'informazione. 
> 

Quello che stanno dicendo alcuni è che, nel dubbio, anche uno solo,
meglio non usare StreetView, meglio non scrivere che potrebbe essere
lecito usarlo, meglio non far credere che sia possibile usarlo.

Ma nessuno ha mai provato a chiederlo direttamente a Google? ;-)

ciao
maxx

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

[Talk-cz] Taginfo CZ

[Tom Ka]

Po upravach hostingu/domen apod prestalo fungovat proxy na
http://taginfo.openstreetmap.cz/.
Michale, bylo by mozne se na to podivat a obnovit provoz?

Diky

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

Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[Jan Dudík]

Depo nemusí nutně znamenat okres.
např.
17704 Depo Praha 704  má
v seznamu schránky nejen na území Prahy, ale i okresů Praha-západ, Beroun a
dokonce i jednu z okresu Příbram.
28400 Kutná Hora LD II  má
v seznamu jedinou schránku
37271 Depo České Budějovice 71
 má i část okresů %Ceský
Krumlov, Prachatice a Jindřichův Hradec

atd.


JAnD
---
Ing. Jan Dudík
projekce dopravních staveb
tel. 777082195

Dne 22. února 2018 12:55 Petr Vozdecký  napsal(a):

> ...no a proc to POI importer posadil do Brna-města na ulici Boří? Když
> hledá Bor, Brno-venkov... To je celé nějak špatně, velmi špatně. Existuje
> autobusová zastávka Bor-rozcestí a to velmi teoreticky na území JM kraje v
> okrese Brno-venkov a navíc co by kamenem dohodil od Nedvědice i od obce
> Bor. Ale rozhodně to nevybírá pošta 60010 (nebo to je údaj, který jsi
> dogeneroval dodatečně?) a na streetview
> 
> tam schranka neni. Je ale v nedaleke obci Bor u autobusove zastavky v obci (
> streetview
> ),
> ale to uz urcite neni Brno-venkov. Leda bychom pripustili, ze to vybira
> posta z Nedvedice, ktera je principialne Brno-venkov (coz by byl zajimavy
> poznatek, ze udaj Brno-venkov nemusi znamenat to, ze se ta posta na uzemi
> Brno-venkov nachazi). A bude to asi ona, protoze tam fyzicky je a v POI
> importeru ji v Boru
> 
> nevidim...
>
> To je ale siiilena detektivka... jak postupovat? Dovozovat takto prisne
> logicky? Co dal? jen to predat "pani z posty" pres Mirka? Bylo by ale
> vhodne k tomu dat zapis do note=*, ktery by se ale mel zobrazit i v tabulce
> POI importeru, aby se mapperi porad nedivili cervenemu spendliku... Protoze
> kdyz venuje nekdo takovy cas patrani, at to ma nejakou odezvu v POI
> importeru, ktera usetri cas dalsim mapperum... :)
>
> vop
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[Simone Saviolo]

Il giorno 22 febbraio 2018 13:02, emmexx  ha scritto:

> On 02/22/2018 12:18 PM, Simone Saviolo wrote:
> > Fammi un esempio di una cosa che hai mappato senza basarti su Street
> > View. E ora smentisci un avvocato ben pagato che dice che l'hai copiato
> > da Street View.
> >
> > Puoi dimostrare che il nome di via Garibaldi non l'hai preso da Street
> > View?
>
> L'onere della prova spetta a chi accusa!
>

Provato: in Street View è chiaramente visibile il cartello con scritto "Via
Garibaldi".

Non ti sembra una prova? Allora descrivimi come dovrebbe essere una prova.

Strano come praticamente solo persone di origine straniera difendano una
> certa posizione...
>

Personalmente, non difendo l'autore del blog di cui si parla in origine di
questo thread. Il fatto stesso che lui dica "ho preso da Street View" lo
pone nel torto, senza se e senza ma.

Quello che interessa a me è dimostrare che una licenza su dati fattuali è
pressoché assurda per definizione. Infatti per farla rispettare si
introducono elementi fittizi... cioè non fattuali. Tra il dato fattuale e
una sua rappresentazione esiste una catena di comunicazioni (l'ho saputo da
X che l'ha saputo da Y che l'ha visto coi suoi occhi), ed è pressoché
impossibile ricostruirla correttamente. Inoltre, è sempre possibile
"assumere" (ma non dimostrare) che in quella catena ci sia almeno un
elemento che vieta la propagazione dell'informazione.

Ovvero: questo (dell'OP) è un caso lampante, ma tutti gli altri non sono
grigi, sono invisibili.

Ciao,

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

Re: [Talk-it] [Imports] Fwd: Re: Sabbioneta buildings import

[Andrea Musuruane]

Hi Giorgio,

On Mon, Feb 19, 2018 at 3:44 PM, Giorgio Limonta <
giorgio.limont...@gmail.com> wrote:

> Why did you avoid "not residential" buildings?
>
> For example, the following building is still not correctly mapped (and it
>> is not the only one):
>> https://postimg.org/image/p3b4wmsgz/
>
>
> yes but that was a problematic one: if I creat two building parts and a
> building feature that contains them, josm validator marks them as an error.
> (perhaps for the particular shape). I solved by erasing the lower part that
> surrounded the main building.
>

It's likely because one of the two building parts must be a multi polygon.

(and it is not the only one)
>
>
> I checked again, I hope it's better now
>

It is better but I still see some issues:
* A bell tower has one tag "man_made:part=tower" which is not documented.
You should use two building:part tags.
* You should also add building=yes to bell towers.
* There is one building with only one building:part=residential tag (there
should be more than one).
* In this same building the entrance part of the house is tagged as a
separate building.
*The previous example is not the only one where a part of a single building
is tagged as different building.

Bye,

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

Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[Miroslav Suchy]

Dne 22.2.2018 v 10:15 majka napsal(a):
> Navíc je v datech pošty několik "*dočasně*" zrušených schránek, na některých 
> místech je tento dočasný stav už zhruba
> rok. Naproti tomu v datech pošty chybí několik *sezónních schránek*, kde


V Brně byla jedna taková v Obřanech, kde byla na fasádě, kde se dělalo 
zateplení. A myslím, že to bylo skoro rok. Já
bych tyhle dočasné nevyhazoval.

Mirek

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

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[Lorenzo "Beba" Beltrami]

Ciao a tutti,
nel leggere questa 30ina di mail ho trovato spunti e punti di vista
interessanti a 360°.
Cerchiamo di non scadere in accuse più o meno personali. O in analisi
statistiche, nel migliore dei casi, parziali.
Il tema è interessante (e infatti gli animi si scaldano!), cerchiamo di
rimanere "in topic".

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

Re: [OSM-talk-fr] recherche autorisation pour ortho Bordeaux et Languedoc-Roussillon

[Vincent Bergeot]

Le 22/02/2018 à 13:35, marc marc a écrit :

Bonjour,

je continue la remise en ordre des couches eli/iD <> josm
Pour 2 couches, je ne trouve pas la mention de la licence permettant de
l'utiliser dans osm :
Bordeaux 2016 (ajout anonyme dans josm il y a 5 mois)
Languedoc-Roussillon 2012 (ajout par Ptigrouick dans josm il y a 3 ans)


sans doute obsolète surtout ?
http://geocatalogue.siglr.org/geonetwork/srv/fr/metadata.show?uuid=4531ef8b-ae5e-4915-9af0-6419b737d47d

je ne suis pas sur de tout bien comprendre mais je dirais que le 2016 
est disponible ?


à plus







Si quelqu'un a l'info :)

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



--
Vincent Bergeot


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

Re: [OSM-talk-fr] recherche autorisation pour ortho Bordeaux et Languedoc-Roussillon

[Vincent Bergeot]

Le 22/02/2018 à 13:35, marc marc a écrit :

Bonjour,

je continue la remise en ordre des couches eli/iD <> josm
Pour 2 couches, je ne trouve pas la mention de la licence permettant de
l'utiliser dans osm :
Bordeaux 2016 (ajout anonyme dans josm il y a 5 mois)


est ce que cela t'aide : https://data.bordeaux-metropole.fr/?new=117309

et la licence : https://data.bordeaux-metropole.fr/license




Languedoc-Roussillon 2012 (ajout par Ptigrouick dans josm il y a 3 ans)

Si quelqu'un a l'info :)

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



--
Vincent Bergeot


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

Re: [Talk-ec] Mejoras a la red de carreteras en Ecuador

[Daniel Orellana]

Hola Andrew.

Te comento que hemos encontrado algunos problemas en las ediciones que está
haciendo tu equipo, en particular el usuario TyFly. He detectado que varias
calles en la ciudad de Cuenca se han cambiado las etiquetas
injustificadamente

Ej 1: Calle sucre es residential y se ha cambiado a tertiary
https://www.openstreetmap.org/way/337277984

Ej 2: Calle Roberto Crespo Toral es Secondary y se ha cambiado a tertiary.
https://www.openstreetmap.org/way/42143234

Por favor indica a tu equipo que revierta estos cambios y que consulte acá
antes de realizar este tipo de cambios ya que nos ha costado mucho tiempo
llegar a consensos.

Una ayuda muy importante para nosotros sería si se puede extender el
trabajo que están haciendo sobre building footprints a Ecuador.


Saludos
Daniel.

___
Daniel Orellana, PhD.
Profesor Principal
Universidad de Cuenca

>> Consulta mi agenda

>> Publicaciones en Google Scholar

>> Perfil en ResearchGate

>> Investigación en LlactaLAB 
>> Investigación en iDRHICA


2018-02-05 13:56 GMT-05:00 Andrew Wiseman :

> Muchas gracias Daniel y Miriam por la información y documents. Se ven muy
> útiles.
>
> Saludos,
>
> Andrew
>
> Andrew Wiseman |  Maps | andrew_wise...@apple.com
>
> APPLE CONFIDENTIAL
> This message (including attachments if any) is for the private use of the
> addressee only and may contain confidential or privileged information. If
> you have received this message by mistake please notify the sender by
> return e-mail and delete this message and any attachments from your system.
> Any unauthorized use or dissemination of this message, and any attachments
> in whole or in part is strictly prohibited.
>
>
>
>
> On Feb 2, 2018, at 12:26 PM, Gonzales, Miriam - (p) 
> wrote:
>
> Hola Daniel + Andrew
>
> Espero se encuentren muy bien, qué gusto saludarlos y saber que el equipo
> de Apple Maps está colaborando en la mejora de los datos en LATAM. Les
> comparto un par de documentos para que puedan ver los avances en Ecuador
> hemos tomado miles de kilómetros de imágenes con OpenStreetCam además de
> que nuestro Mapping Team ha estado trabajando en la mejora de los datos de
> calles y carreteras. Los retos principales a los que nos seguimos
> enfrentando es cómo agregar los nombres de las calles y los POIs
>
> Presentación de Avances en Ecuador
> https://www.slideshare.net/MiriamGonzalez49/mejorando-datos-
> de-caminos-y-carreteras-usando-openstreetcam
>
> Captura de Imágenes en Ecuador con OpenStreetCam
> http://www.openstreetcam.org/map/@-1.8541685045484668,-79.19
> 714368879796,8z
>
> Saludos y gracias,
>
> M
>
> *From:* Daniel Orellana [mailto:daniel.orell...@ucuenca.edu.ec
> ]
> *Sent:* Thursday, February 1, 2018 5:55 AM
> *To:* OpenStreetMap Ecuador 
> *Subject:* Re: [Talk-ec] Mejoras a la red de carreteras en Ecuador
>
> Hola Andrew.
>
> Bienvenido a la comunidad OSM de Ecuador. Que bien que puedan sumarse a
> los esfuerzos para mejorar el mapa de Ecuador. Aunque la comunidad no es
> muy grande, somos algunos contribuyentes que estamos pendientes de lo que
> se puede hacer.
>
> Los problemas más frecuentes en el mapa de Ecuador son (probablemente en
> ese orden):
>
> 1. Completar vías terciarias / unclassified, principalmente fuera de zonas
> urbanas.
> 2. Consistencia topológica en las vías dentro de zonas urbanas.
> 3. Elementos importantes para la movilidad no motorizada (peatones y
> bicicletas) tales como aceras, andenes, pasos peatonales, ciclovías, etc.
>
> También te comento que la empresa TELNAV ha estado colaborando también en
> el mapa desde hace algunos meses.
>
>
> Saludos cordiales,
>
> daniel.
>
>
> ___
> Daniel Orellana, PhD.
> Profesor Principal
> Universidad de Cuenca
>
> >> Consulta mi agenda
> 
> >> Publicaciones en Google Scholar
> 
> >> Perfil en ResearchGate
> 
> >> Investigación en LlactaLAB
> 

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[emmexx]

On 02/22/2018 01:34 PM, Cascafico Giovanni wrote:
> Qua non si tratta di alludere allo stereotipo dell'italiano maneggione,
> ma di capire cosa siano le parole "creare", "integrare" ("create",
> "augment").

Stereotipo?

> 
> Una nota in OSM è indubbiamente un'informazione, ma non crea il POI ne'
> tantomeno lo integra/completa. Cosa devo dimostrare ancora?


Una nota è parte di osm esattamente come tutto il resto.
Se tu guardi su Streetview e vedi che in un punto c'è il "Bar dello
sport", poi metti una nota in osm e ci scrivi "Verificare che qui c'è il
Bar dello Sport" stai aumentando le informazioni di OSM prendendole da
Google.

ciao
maxx

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

Re: [OSM-talk-fr] une ou deux way ? 2 ways s'il y a un obstacle.

[Jérôme Seigneuret]

Les surfaces c'est pas forcément simple (double représentation ducoup) et
ok pour les carrefours d'ailleurs concernant la circulation à double sens
sur un carrefour avec feu et voie principale à sens unique, j'ai du
supprimer la partie en sens unique.

https://www.openstreetmap.org/way/557610710


Le 21 février 2018 à 18:52, Erwan Salomon  a écrit :

> de prime abord j’aurais tendance à utiliser pour ce genre de cas :
> traffic_calming=island
> https://wiki.openstreetmap.org/wiki/Tag:traffic_calming%3Disland
> à ajouter sur une portion du way
> sans doute à compléter avec des interdictions de tourner à gauche à
> certains carrefours
> voir juste un passage piéton avec la précision crossing=island
> https://wiki.openstreetmap.org/wiki/Key:crossing
>
> sinon un rendu qui prendrait en compte lanes=# pour dessiner la largeur
> des highway ça serait pas mal aussi
> ça donnerait un rendu plus proche de la réalité et qui limiterait l’envie
> de passer en surfacique (qui me semble une mauvaise option proche du tag
> pour le rendu)
> ça rendrait aussi les transition sur les séparation de chemin plus
> esthétiques notamment dans les cas comme cette « Route de la Reine »
>
> Le 21 févr. 2018 à 14:45, Thomas Ruchin  a écrit :
>
> Attention, ce n'est pas si évident que cela. Quand on le pratique de
> manière jusqu'au boutiste, cela donne des résultats bizarres
> https://www.openstreetmap.org/?mlat=48.83928=2.24425#
> map=18/48.83928/2.24425
> Pour ceux qui connaissent le secteur, heureusement que le Boulevard de
> Magenta à Paris n'est pas cartographié selon la même manière que la Route
> de la Reine à Boulogne
>
> Comme le rappelle Christian, le principal objectif d'avoir des voies
> séparées dans OSM est l'aide au routage. Si la chaussée est la même, il
> faut se poser la question de la pertinence de scinder la voie.
>
> Thomas Ruchin
>
> Le 21 février 2018 à 12:21, Cyrille37 OSM  a
> écrit :
>
>> Le 21/02/2018 à 10:28, Christian Quest a écrit :
>>
>>> Pour moi tout ce qui oblige à faire un choix de passer "à gauche ou à
>>> droite" (donc routage) est un obstacle.
>>> Une bande réservée au stationnement est aussi pour moi un obstacle vu
>>> qu'on va devoir choisir par où passer.
>>>
>>
>> +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
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-ec] Cambios en Cuenca

[Daniel Orellana]

Hola comunidad.

Les comento que el usuario TyFly ha estado realizando cambios en el mapa
Ecuador y algunos de ellos sin correspondencia a los esfuerzos de
normalización que hemos tenido en la comunidad.

Aquí copio el mensaje que le he enviado.

Hi Tyler!

Welcome to the Ecuador OSM project.

I've seen your last contributions for OSM Ecuador. Thanks for your help and
hope you will keep improving the map and participating on the community.

I realized you changed some highway tags in Cuenca for some reason without
the input of the local community.

Ej: Sucre and Bolivar streets are residential, no tertiary.
https://www.openstreetmap.org/way/337277984#map=16/-2.8984/-79.0028

Would you please revert back your changes accordingly?  We've put a lot of
effort on keeping the map accurrate and following the local concensus.

At the same time, I invite you to participate on the talk-ec mailing list
and #mappingecuador channel on telegram to discuss any doubt you might have.

https://t.me/mappingEcuador
https://t.me/joinchat/AD5SAe4T9h195r8lmA

Best,

Daniel

(pd. You can reach me directly at daniel.orell...@ucuenca.edu.ec)
___
Daniel Orellana, PhD.
Profesor Principal
Universidad de Cuenca

>> Consulta mi agenda

>> Publicaciones en Google Scholar

>> Perfil en ResearchGate

>> Investigación en LlactaLAB 
>> Investigación en iDRHICA


-- 
Advertencia legal: 
Este mensaje y, en su caso, los archivos anexos son confidenciales, 
especialmente en lo que respecta a los datos personales, y se dirigen 
exclusivamente al destinatario referenciado. Si usted no lo es y lo ha 
recibido por error o tiene conocimiento del mismo por cualquier motivo, le 
rogamos que nos lo comunique por este medio y proceda a destruirlo o 
borrarlo, y que en todo caso se abstenga de utilizar, reproducir, alterar, 
archivar o comunicar a terceros el presente mensaje y ficheros anexos, todo 
ello bajo pena de incurrir en responsabilidades legales. Las opiniones 
contenidas en este mensaje y en los archivos adjuntos, pertenecen 
exclusivamente a su remitente y no representan la opinión de la Universidad 
de Cuenca salvo que se diga expresamente y el remitente esté autorizado 
para ello. El emisor no garantiza la integridad, rapidez o seguridad del 
presente correo, ni se responsabiliza de posibles perjuicios derivados de 
la captura, incorporaciones de virus o cualesquiera otras manipulaciones 
efectuadas por terceros.
___
Talk-ec mailing list
Talk-ec@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ec

Re: [Talk-at] "geocodec/Socke/Johann Haag" stummschalten

[Johann Haag]

wenn du kompetenztechnisch nicht mitreden kannst, was machst du dann hier in 
einem OSM Forum. Dir ist aber schon bewusst dass Deine Stimme hier als 
Vollwertig in OSM Entscheidungen gilt.  

Grüsse Johann
osm wiki the map

Von meinem iPhone gesendet

> Am 22.02.2018 um 11:40 schrieb Marcus MERIGHI :
> 
> Ich kann kompetenztechnisch inhaltlich nicht mitreden; aber ich merke,
> wenn einer immer das selbe sagt, argumentativ widerlegt wird - und
> wieder dasselbe sagt. 
> 
> Netiquette ist Ihm auch egal, seine E-Mails sind muehsam zu lesen. 
> 
> Wenn ich so ein Verhalten erleben will dann halte ich lieber einen
> Kletterkurs fuer Jugendliche.
> 
> Er ist ja so ein armes Opfer. Alle sind gegen Ihn.
> Dunning-Kruger-Effekt. Troll.
> 
> https://www.mail-list.com/how-to-deal-with-trolls-in-your-listserv/
> http://www.crydee.com/raymond-feist/faq/4164/how-to-handle-trolls-on-the-mailing-list
> https://kotaku.com/10-former-internet-trolls-explain-why-they-quit-being-j-1722649439
> 
> Marcus
> 
> johannh...@hxg.at (Johann Haag), 2018.02.22 (Thu) 00:45 (CET):
>> Hallo Rudi,
>> Meine Fragestellung zur Wiener Adress Besonderheit im osm Forum war
>> rechtzeitig und klar, aber man hat mich dort links liegen gelassen,
>> und mich ganz offen in einen 20k Edit hineinrennen lassen. Nicht ich
>> war jener der die Diskussion verweigert hat.
>> Erst als ich die Sachlage anschlie??end in Eigenregie selbst eruiert
>> hatte, heisst es pl??tzlich, das haben wir doch alles l??ngst gewusst.
>> Das nennt man einen f??r Dumm verkaufen.
>> 
>> Nun nachdem eine einfache L??sung durch Mappen vorerst wenigstens der
>> Basisadressen vorliegt, wird wieder gemauert was das Zeug h??lt, und
>> auch noch im GitHub Forum suggestiv geflennt.
>> 
>> Das ist doch alles nur noch peinlich. Es wird keine Verbesserung in
>> der OSM Adress Situation gewollt. Und der Ober Guru dieser Aktion ist
>> auch noch Kassier im osm Verein AT.
>> Mein Misstrauensantrag an diesen.
>> 
>> Gre Johann
>> Osm: wiki the map
>> 
>>> Am 22.02.2018 um 00:09 schrieb Rudolf Mayer :
>>> 
>>> Hallo!
>>> 
>>> Sorry f??r den Vollquottel unten, aber Andreas, du sprichst mir hier aus 
>>> der Seele mit deiner Antwort.
>>> 
>>> 
>>> @Johann, ich verstehe nicht, was genau Deine Motivation ist. Du 
>>> unterstellst allen anderen, dass sie keine besseren Daten haben wollen.
>>> 
>>> Und was machst du - du f??gst unn??tige Duplikate ein (und ja, es
>>> ist gut dass Deine 20.000 Adressen gel??scht wurden, da war vorher
>>> von Dir keinerlei Kontrolle was du ??berschreibst / duplizierst, so
>>> geht das einfach nicht), nur damit *eine* Anwendung, ??ber welche
>>> die Entwickler selber sagen, dass sie kaputt ist, irgendwie
>>> funktioniert? Das kann es ja wirklich nicht sein, so stur, das ist
>>> schon surreal.
>>> 
>>> Deine Nachrichten sind teilweise sehr m??hsam zu lesen. Z.B. wenn Du
>>> da proklamierst, das "Adressr??tsel" gel??st zu haben (wenn du aber
>>> nur best??tigt hast, was dir andere (z.b. fkv) schon mehrmals gesagt
>>> haben; wenn Du dauernd das selbe wiederholst und einen bestimmten
>>> Hack in den Daten machen willst, obwohl Dir genug Kollegen
>>> widersprechen, etc. Wenn du jeden beschuldigst, ein Feind von guten
>>> Daten zu sein...
>>> 
>>> Und ich habe da von Dir auch keinerlei Vorschlag gesehen, wie ein
>>> zuk??nftiger Import das besser machen w??rde, wie du Duplikate
>>> filtern oder bereinigen willst.
>>> 
>>> Ich w??rde vorschlagen, ??ber das mal zu reflektieren, und nicht
>>> gleich anzunehmen, dass hier die "b??se Wiener Gang" einen
>>> schlechten Datenbestand verteidigen will..
>>> Ich bin selber 1/4 Tiroler, 3/4 Steirer, aber nun mal grtenteils
>>> in Wien unterwegs, und ich h??tte bis jetzt nicht das Gef??hl
>>> gehabt, dass da eine generelle Abneigung zu Mappern, die nicht nur
>>> Wiener Blut haben, gibt :-) Ich glaube, das liegt eher an deinem
>>> unausgereiftem Vorschlag und gro??em Import, der vorher einfach
>>> nicht diskutiert wurde. Und darauf hast du dann eigentlich nur
>>> patzig reagiert, anstatt einen Fehler in der Vorgehensweise
>>> einzusehen, und das in Ruhe zu diskutieren.
>>> 
>>> Also, bitte, ein paar mal tief durchatmen, und nicht gleich in den
>>> Berserkermodus wechseln.
>>> 
>>> Lg
>>> Rudi
>>> 
>>> 
>>> P.s.: Weil du oft mal auch Google Maps als Vorbild nennst - wenn du
>>> mal wirklich in so einer komplexen Wohnanlage routen willst,
>>> schaffen die das auch nicht, weil einfach viele Gehwege nicht
>>> bekannt sind. Das ist nicht einmal nur immer in den Wohnanlagen der
>>> Fall, sondern auch oft gibt es in Wien (und nicht nur dort!) viele
>>> H??userdurchl??sse, Treppen, etc. die Google nicht kennt. Also so
>>> alles eitel Wonne ist dort auch nicht. Aber klar, die POI Suche, die
>>> ??hnlichkeitssuche, das ist um Welten besser.
>>> 
>>> 
 On 02/21/2018 09:15 PM, andreas wecer wrote:
 On Tue, Feb 20, 2018 at 9:55 AM > 

[OSM-talk-fr] recherche autorisation pour ortho Bordeaux et Languedoc-Roussillon

[marc marc]

Bonjour,

je continue la remise en ordre des couches eli/iD <> josm
Pour 2 couches, je ne trouve pas la mention de la licence permettant de 
l'utiliser dans osm :
Bordeaux 2016 (ajout anonyme dans josm il y a 5 mois)
Languedoc-Roussillon 2012 (ajout par Ptigrouick dans josm il y a 3 ans)

Si quelqu'un a l'info :)

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

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[Cascafico Giovanni]

Qua non si tratta di alludere allo stereotipo dell'italiano maneggione, ma
di capire cosa siano le parole "creare", "integrare" ("create", "augment").

Una nota in OSM è indubbiamente un'informazione, ma non crea il POI ne'
tantomeno lo integra/completa. Cosa devo dimostrare ancora?



Il giorno 22 febbraio 2018 13:02, emmexx  ha scritto:

>
> I casi in cui Google vincerebbe facilmente una causa sono abbastanza
> ovvi. Ed è cosa nota che nelle mappe (o nei dizionari) vengano inseriti
> di proposito elementi errati in attesa che qualcuno li copi.
>
> Strano come praticamente solo persone di origine straniera difendano una
> certa posizione...
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[Marco_T]

emmexx wrote
> L'onere della prova spetta a chi accusa!

Io inviterei zendam a leggere bene le Licenze ed a cercare di capirle
autonomamente. Chi mappa deve essere pienamente responsabile di quello che
fa.
Se poi ha dei dubbi il mio consiglio è quello di rimuovere quella dicitura
(che, a mio parere, può essere un ottimo pretesto per chi accusa).

Saluti.

-- 
Marco_T



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

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

Re: [OSM-talk-fr] Zones géographiques informelles

[Francescu GAROBY]

Bien sûr que si, un node est trouvable sur une carte ! Sinon, on ne
pourrait pas trouver les commerces/numéros de rue/... quand on fait une
recherche !

Francescu

Le 22 février 2018 à 12:40, Philippe Verdy  a écrit :

> Un node est introuvable sur une carte, impossible à représenter quel que
> soit le niveau de zoom... On doit pouvoir tracer quelquechose estimatif
> donnant une idée correcte de l'étendue (j'ai donné l'exemple des communes
> africaines ou des frontières terrestres des émirats ou les baies maritimes,
> on ne s'en sort pas du tout avec un simple noeud. On peut donner d'autres
> exemples avec les massifs montagneux.
> Cela concerne autant les boundary=* (même administrative), natural=*,
> water=*
> Un tag supplémentaire devrait être défini et le moteur de rendu devrait
> pouvoir s'adapter pour ne pas tracer un trait trop marqué comme absolu.
> Pour les frontières administratives, le rendu serait des tirets discontinus
> suffisamment espacés.
>
> Le 22 février 2018 à 12:32, Francescu GAROBY  a écrit
> :
>
>> À défaut de frontières bien définies, un node, placé à peu près au centre
>> de la zone concernée, ça n'irait pas ?
>>
>>


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

Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[majka]

Opět se do toho vložím -* stačí číst:*
*POZOR:* Souřadnice jsou pouze *orientační*!
Přesné umístění nutno dohledat dle poznámky!

Tohle vychází z geokódování, a chyby tam jsou a budou.

*Správný postup:*
V tomhle konkrétním případě není problém pošty, ale můj (geokódování).

Jsou dvě možnosti:
1. vím jak to má být správně:
Zadám schránku do OSM, včetně všech informací, počkám, až se zaktualizuje.
Vzhledem k tomu, že u schránek, které jsou včetně ref v OSM se vezme
skutečná pozice, problém při příští aktualizaci odstraní

2. nevím, jak to má být správně, ale vím že TOHLE je blbě:
pošlu zprávu sem a někdo jiný se o to nějak postará

Ta data jsou veřejně přístupná, pokud Tě to zajímá, můžeš si je stáhnout

.

Fakt tu situaci komplikuješ mnohem víc, než to ve skutečnosti je. Pokud tě
zajímá přesný postup, napiš mi mimo list.

Majka


2018-02-22 12:55 GMT+01:00 Petr Vozdecký :

>
> To je ale siiilena detektivka... jak postupovat? Dovozovat takto prisne
> logicky? Co dal? jen to predat "pani z posty" pres Mirka? Bylo by ale
> vhodne k tomu dat zapis do note=*, ktery by se ale mel zobrazit i v tabulce
> POI importeru, aby se mapperi porad nedivili cervenemu spendliku... Protoze
> kdyz venuje nekdo takovy cas patrani, at to ma nejakou odezvu v POI
> importeru, ktera usetri cas dalsim mapperum... :)
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[Petr Vozdecký]

Pises "do statistik". Bylo by asi efektivnejsi generovat "rozdilovy soubor",
tedy v tomto pripade seznam schranek, ktere jsou v OSM a ktere nejsou zatim
naparovany. Tyto zobrazovat v POI importeru jako samostatnou vrstvu. Tim 
bych totiz asi jako mapper zacal, protoze mam vetsi duveru v geografickou 
presnost techto dat... A k temto datum bych v prvni rade dohledaval
"zatolulane" schranky z dat CP...


-- Původní e-mail --
Od: Marián Kyral 
""- (jednosměrnost) v POI importeru vidím vizualizované jen ty schránky,
které jsou v externí datové sadě České pošty? Tedy pokud oni něco nemají a
my ano, je to nějak vizualizováno?"



Ano. POI-Importer funguje tak, že externí data jsou správně. Vizualizaci
dat, která v datasetu nejsou neumí (a asi by bylo trochu komplikované to tam
dopsat).

Nicméně plánuji přidat do statistik stránku s přehledem nespárovaných
schránek (jsou v OSM, ale nemají ref, nebo mají jiného operátora).





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

Re: [Talk-it] risposta a dichiarazione uso di GoogleStreetView

[emmexx]

On 02/22/2018 12:18 PM, Simone Saviolo wrote:
> Fammi un esempio di una cosa che hai mappato senza basarti su Street
> View. E ora smentisci un avvocato ben pagato che dice che l'hai copiato
> da Street View. 
> 
> Puoi dimostrare che il nome di via Garibaldi non l'hai preso da Street
> View? 

L'onere della prova spetta a chi accusa!

I casi in cui Google vincerebbe facilmente una causa sono abbastanza
ovvi. Ed è cosa nota che nelle mappe (o nei dizionari) vengano inseriti
di proposito elementi errati in attesa che qualcuno li copi.

Strano come praticamente solo persone di origine straniera difendano una
certa posizione...

ciao
maxx

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

Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[Petr Vozdecký]

...s evidentnimi BAD-DATA se peru v dalsim pripade - POI importer (resp. 
data Ceske posty) tvrdi, ze existuje schranka na adrese Libušina třída 3 v
Brně-Kohoutovicich (viz zde
(http://osm.kyralovi.cz/POI-Importer-testing/#map=18/49.1985/16.5339=CZECPbox)
). To je ale nesmysl, takové adresní místo neexistuje a poblíž místa, které
by se za takovou adresu dalo považovat (tedy geograficky mezi existujícími
adresními body s cislem orientacnim 1 a 9) je jina konkretni schranka. Cili
mam v Kohoutovicich jednu schranku navic a to i kdyz vezmu v uvahu otazku,
ze tam vsechny schranky znam a ze rozlozeni techto identifikovanych schranek
pokryva rovnomerne cele sidliste, tedy nejsem schopen ani tipnout, kde by 
mohla byt "skryta ve krovi"...

Mohlo by mi pomoci znat, jak ta data vypadaji ve zdroji a to i v kontextu s
jinymi daty (muze jit o data/adresu evidentne z jineho mesta) - dostanu se
ja jednoduse k tomu zdroji?

Dalsi cesty jak patrat me zatim nenapadaji - predpokladam, ze mail na postu
pres Mirka Sucheho bude mit jen odpoved "v datech to mame, asi to existuje,
rusit to v datech jen na zaklade vaseho podezreni nebudeme"... :)

vop

-- Původní e-mail --
Od: Marián Kyral 
"
Ahoj,
trochu jsem znejistěl, ale nakonec to vypadá na chybu v datech ČP:

60012;Depo Brno 73;67autobusová zastávka,
Bor;Nedvědice;Nedvědice;Brno-venkov;08:15;1-5 - pracovní dny (pondělí až
pátek)

Jaký je skutečný stav, asi budeš muset zjistit sám ;-)

Marián

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

Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[Petr Vozdecký]

...no a proc to POI importer posadil do Brna-města na ulici Boří? Když hledá
Bor, Brno-venkov... To je celé nějak špatně, velmi špatně. Existuje
autobusová zastávka Bor-rozcestí a to velmi teoreticky na území JM kraje v
okrese Brno-venkov a navíc co by kamenem dohodil od Nedvědice i od obce Bor.
Ale rozhodně to nevybírá pošta 60010 (nebo to je údaj, který jsi dogeneroval
dodatečně?) a na streetview
(https://www.google.cz/maps/@49.4459742,16.287831,3a,75y,77.9h,85.33t/data=!3m10!1e1!3m8!1smh-thZKGD8R50VRne_SE9g!2e0!6s%2F%2Fgeo0.ggpht.com%2Fcbk%3Fpanoid%3Dmh-thZKGD8R50VRne_SE9g%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D34.02659%26pitch%3D0%26thumbfov%3D100!7i13312!8i6656!9m2!1b1!2i32?hl=cs)
tam schranka neni. Je ale v nedaleke obci Bor u autobusove zastavky v obci (
streetview
(https://www.google.cz/maps/@49.4382377,16.2893575,3a,75y,46.49h,91.89t/data=!3m7!1e1!3m5!1sVkceOMRRwcuO1U0MZpQgnQ!2e0!6s%2F%2Fgeo3.ggpht.com%2Fcbk%3Fpanoid%3DVkceOMRRwcuO1U0MZpQgnQ%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D331.53705%26pitch%3D0%26thumbfov%3D100!7i13312!8i6656?hl=cs)
), ale to uz urcite neni Brno-venkov. Leda bychom pripustili, ze to vybira
posta z Nedvedice, ktera je principialne Brno-venkov (coz by byl zajimavy 
poznatek, ze udaj Brno-venkov nemusi znamenat to, ze se ta posta na uzemi 
Brno-venkov nachazi). A bude to asi ona, protoze tam fyzicky je a v POI 
importeru ji v Boru
(http://osm.kyralovi.cz/POI-Importer-testing/#map=15/49.4381/16.2885=CZECPbox)
nevidim...

To je ale siiilena detektivka... jak postupovat? Dovozovat takto prisne 
logicky? Co dal? jen to predat "pani z posty" pres Mirka? Bylo by ale vhodne
k tomu dat zapis do note=*, ktery by se ale mel zobrazit i v tabulce POI
importeru, aby se mapperi porad nedivili cervenemu spendliku... Protoze kdyz
venuje nekdo takovy cas patrani, at to ma nejakou odezvu v POI importeru, 
ktera usetri cas dalsim mapperum... :)

vop

-- Původní e-mail --
Od: Marián Kyral 
Komu: talk-cz@openstreetmap.org
Datum: 22. 2. 2018 7:16:48
Předmět: Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )
"Dne 21.2.2018 v 18:09 Petr Vozdecký napsal(a):
> ...dotaz - toto je nějaká chyba?
>
> https://ulozto.cz/!dcciRBZSNda6/quickmemo-2018-02-21-18-03-22-png
>
> http://osm.kyralovi.cz/POI-Importer-testing/#map=18/49.2870/16.6360;
datasets=CZECPbox
>
> bod se z pohledu hodnoty ref tvari, ze tam patri, z pohledu poznamky, ze
tam je uplne omylem. Bod je v mistni casti Utechov v Brne a
> odkazuje na obec Nedvedice... V Nedvedici by ale takove ref rozhodne
nebylo...

Ahoj,
trochu jsem znejistěl, ale nakonec to vypadá na chybu v datech ČP:

60012;Depo Brno 73;67autobusová zastávka,
Bor;Nedvědice;Nedvědice;Brno-venkov;08:15;1-5 - pracovní dny (pondělí až
pátek)

Jaký je skutečný stav, asi budeš muset zjistit sám ;-)

Marián


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

Re: [OSM-talk-be] Where to suggest/discuss the renderer?

[marc marc]

HEllo,

Since the rendering is aware of the problem and its answer is "there's a 
schema missing able to be used." :
- make a fork of rendering is useless if the data does not exist
- it is enough to make a proposed feature to fill the gap.

Regard,
Marc

Le 22. 02. 18 à 10:41, Glenn Plas a écrit :
> Mapping for the renderer is de facto wrong and what you experience now
> (in france etc.) is the endresult of that attitude.  I don't understand
> why you get discouraged on OSM because of a map you don't like.   It's
> like saying:  "I don't contribute to Wikipedia anymore because when I
> print a page out, it's not aligned the way I want it."
> 
> There are several options for anyone in your situation:
> 
> 1. make your own map.  There are several sites that allow you to make
> custom maps.
> 2. more technical: copy cartoCSS, change whatever you want, set up a
> tile server and enjoy your perfectly suited map
> 3. try to change the consensus, lobby for universal solution, try to get
> the standard cartoCSS changed to your likings (and repeat later when
> someone else does the same)
> 4. Look for existing map alternatives  (different renderings)
> 
> You should realise that it has nothing to do with the source data.
> There are already ton's of different map rendering out there, perhaps
> one will be perfect for you.
> 
> Don't stop mapping because of someone elses decision to represent a
> feature in a way that doesn't appeal to you.  It's the worst reason to
> stop as that might just change in an instant.
> 
> Glenn
> 
> 
> On 19-01-18 16:43, Karel Adams wrote:
>> When I first consulted maps - paper-only, at that time, of course -
>> the famous Michelin 1:20 had distinct symbols for (bigger)
>> airports, (smaller) airfields, and glider fields. As of 2018, the
>> generic map of openstreetmap has only a single icon to represent
>> anything mapped with "aeroway:aerodrome" - and all of them rendered as
>> from zoomlevel=13 - and none below.
>>
>> This is really very bad. Why should I want to contribute to a system
>> that delivers poorer info than paper maps of 50 years old?
>>
>> Even worse, many active and able mappers are reluctant to update the
>> database properly because the correct info will be so poorly rendered.
>> Especially in France and Italy, where I had endless arguments with
>> people removing the "aeroway=aerodrome" tag from real proper
>> aerodromes, because they didn't want their local grass runway mapped
>> the same as CDG Roissy airport. Even if I don't agree, I can fully
>> understand their point of view!
>>
>> What is the proper place to question this matter, and discuss schemes
>> of improvement? Is there a discussion site for the renderer?
>>
>>
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
> 
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 

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

Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[majka]

Dovolím si odpovědět za Mariána:
hlavní problém je, že je třeba to párování aktualizovat, což se dva dny
nestalo, pokud chápu dobře.
V této chvíli se páruje se primárně přes ref, přes vzdálenost jen pokud už
ke spárování přes ref nedošlo.

Hlavní ale je: dokud nedojde k aktualizaci u Mariána, rozdíl tam zůstane.
Nestačí opravit data OSM.

Majka

2018-02-22 12:28 GMT+01:00 Petr Vozdecký :

> ...tedy primarni vlastnost pro parovani (situace, kdy POIimporter vi, co
> chce v tabulce porovnavat) je vzdalenost? Hraje tam nejakou roli ref=*?
>
> vop
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk-fr] Zones géographiques informelles

[Philippe Verdy]

Un node est introuvable sur une carte, impossible à représenter quel que
soit le niveau de zoom... On doit pouvoir tracer quelquechose estimatif
donnant une idée correcte de l'étendue (j'ai donné l'exemple des communes
africaines ou des frontières terrestres des émirats ou les baies maritimes,
on ne s'en sort pas du tout avec un simple noeud. On peut donner d'autres
exemples avec les massifs montagneux.
Cela concerne autant les boundary=* (même administrative), natural=*,
water=*
Un tag supplémentaire devrait être défini et le moteur de rendu devrait
pouvoir s'adapter pour ne pas tracer un trait trop marqué comme absolu.
Pour les frontières administratives, le rendu serait des tirets discontinus
suffisamment espacés.

Le 22 février 2018 à 12:32, Francescu GAROBY  a écrit :

> À défaut de frontières bien définies, un node, placé à peu près au centre
> de la zone concernée, ça n'irait pas ?
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Zones géographiques informelles

[marc marc]

Bonjour,

soit un nœud au milieu
soit un polygone avec source:geometry=estimated pour une fois
sur l'objet

Cordialement,
Marc

Le 22. 02. 18 à 11:36, David Marchal a écrit :
> Bonjour.
> 
> 
> Pour avoir déjà cherché comment faire, je peux te dire que le problème 
> principal est de donner les limites de ces zones : comme la limite 
> en est floue car non définie avec certitude – on ne peut dire avec 
> certitude, surtout sur les bordures, que tel endroit en fait partie et 
> tel autre, non –, on ne peut pas les modéliser. Si tu as une source 
> disant que la région, par exemple, inclut uniquement telles communes, tu 
> peux modéliser, mais justement, ces sources sont généralement 
> inexistantes ou contradictoires, donc, sans bases fiables, impossible de 
> modéliser. Autant que je sache, quand c’est flou, on ne modélise pas.
> 
> 
> Cordialement.
> 
> 
> 
> *De :* djakk djakk 
> *Envoyé :* mercredi 21 février 2018 20:01
> *À :* Discussions sur OSM en français
> *Objet :* [OSM-talk-fr] Zones géographiques informelles
> Re-salut,
> 
> une question sur le sujet des zones géographiques : comment tagguer 
> celles qui sont « informelles » (non-administratives), dont la limite 
> est floue : la vallée de la Vésubie, la corniche de Pail, la Beauce ...
> On retrouve trace de ces noms dans la presse locale.
> 
> 
> djakk
> 
> 
> ___
> 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] Zones géographiques informelles

[Francescu GAROBY]

À défaut de frontières bien définies, un node, placé à peu près au centre
de la zone concernée, ça n'irait pas ?

Francescu


Le 22 février 2018 à 12:29, Philippe Verdy  a écrit :

> Ne pas taguer est pire que tout. Les limites comunales africaine sont
> souvent estimées et ne rien mettrre veut dire qu'on ne trouvera pas du tout
> ces communes.
> Je pense qu'on doit pouvoir tracer tout en indiquant la marge
> d'incertitude. Même chose concernant les frontières entre les émirats
> arabes (la limite est floue aussi, c'est une frontière naturelle non
> matérialisée, le désert) pourtant il y a besoin d'en faire un type
> "boundary=adminsitrative".
>
> Là encore on doit pouvoir s'en sortie en traçant un polygone estimatif et
> ajoutant un tag d'incertitude. Idem pour les extensions des glaciers : ne
> rien mettre veut dire ne pas faire figurer le glacier du tout, ce qui est
> pire que de le représenter avec une limite estimative.
>
> Après on doit faire un choix de rendu pour que ces frontières soient aussi
> rendues comme floues (dans la limite de l'incertitude donnée en distance
> autour du chemin). Les recherches par Nominatim devraient alors trouver ces
> objets.
>
>
> Le 22 février 2018 à 11:36, David Marchal  a écrit :
>
>> Bonjour.
>>
>>
>> Pour avoir déjà cherché comment faire, je peux te dire que le problème
>> principal est de donner les limites de ces zones : comme la limite en est
>> floue car non définie avec certitude – on ne peut dire avec certitude,
>> surtout sur les bordures, que tel endroit en fait partie et tel autre, non
>> –, on ne peut pas les modéliser. Si tu as une source disant que la région,
>> par exemple, inclut uniquement telles communes, tu peux modéliser, mais
>> justement, ces sources sont généralement inexistantes ou contradictoires,
>> donc, sans bases fiables, impossible de modéliser. Autant que je sache,
>> quand c’est flou, on ne modélise pas.
>>
>>
>> Cordialement.
>>
>> --
>> *De :* djakk djakk 
>> *Envoyé :* mercredi 21 février 2018 20:01
>> *À :* Discussions sur OSM en français
>> *Objet :* [OSM-talk-fr] Zones géographiques informelles
>>
>> Re-salut,
>>
>> une question sur le sujet des zones géographiques : comment tagguer
>> celles qui sont « informelles » (non-administratives), dont la limite est
>> floue : la vallée de la Vésubie, la corniche de Pail, la Beauce ...
>> On retrouve trace de ces noms dans la presse locale.
>>
>>
>> djakk
>>
>> ___
>> 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
>
>


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

Re: [Talk-lt] Karo laikų vokiečių ortofoto

[Darius Žitkevičius]

Super!!! :)

2018-02-22 11:44 GMT+02:00 Paulius Zaleckas :

> Šiuo metu sakė sukelta 600 kadrų iš 17000. Neužilgo bus daugiau.
>
> https://lcva.maps.arcgis.com/apps/StorytellingSwipe/index.html?appid=
> 55427117cc974807abf0f99af0487144
>
> ___
> Talk-lt mailing list
> Talk-lt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-lt
>



-- 
Darius Žitkevičius

Laimingas tas, kuris džiaugsmingai dirba ir džiaugiasi darbais, kuriuos
padarė. – J. V. Gėtė.
___
Talk-lt mailing list
Talk-lt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lt

Re: [OSM-talk-fr] Zones géographiques informelles

[Philippe Verdy]

Ne pas taguer est pire que tout. Les limites comunales africaine sont
souvent estimées et ne rien mettrre veut dire qu'on ne trouvera pas du tout
ces communes.
Je pense qu'on doit pouvoir tracer tout en indiquant la marge
d'incertitude. Même chose concernant les frontières entre les émirats
arabes (la limite est floue aussi, c'est une frontière naturelle non
matérialisée, le désert) pourtant il y a besoin d'en faire un type
"boundary=adminsitrative".

Là encore on doit pouvoir s'en sortie en traçant un polygone estimatif et
ajoutant un tag d'incertitude. Idem pour les extensions des glaciers : ne
rien mettre veut dire ne pas faire figurer le glacier du tout, ce qui est
pire que de le représenter avec une limite estimative.

Après on doit faire un choix de rendu pour que ces frontières soient aussi
rendues comme floues (dans la limite de l'incertitude donnée en distance
autour du chemin). Les recherches par Nominatim devraient alors trouver ces
objets.


Le 22 février 2018 à 11:36, David Marchal  a écrit :

> Bonjour.
>
>
> Pour avoir déjà cherché comment faire, je peux te dire que le problème
> principal est de donner les limites de ces zones : comme la limite en est
> floue car non définie avec certitude – on ne peut dire avec certitude,
> surtout sur les bordures, que tel endroit en fait partie et tel autre, non
> –, on ne peut pas les modéliser. Si tu as une source disant que la région,
> par exemple, inclut uniquement telles communes, tu peux modéliser, mais
> justement, ces sources sont généralement inexistantes ou contradictoires,
> donc, sans bases fiables, impossible de modéliser. Autant que je sache,
> quand c’est flou, on ne modélise pas.
>
>
> Cordialement.
>
> --
> *De :* djakk djakk 
> *Envoyé :* mercredi 21 février 2018 20:01
> *À :* Discussions sur OSM en français
> *Objet :* [OSM-talk-fr] Zones géographiques informelles
>
> Re-salut,
>
> une question sur le sujet des zones géographiques : comment tagguer celles
> qui sont « informelles » (non-administratives), dont la limite est floue :
> la vallée de la Vésubie, la corniche de Pail, la Beauce ...
> On retrouve trace de ces noms dans la presse locale.
>
>
> djakk
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[Petr Vozdecký]

...tedy primarni vlastnost pro parovani (situace, kdy POIimporter vi, co 
chce v tabulce porovnavat) je vzdalenost? Hraje tam nejakou roli ref=*?

vop

-- Původní e-mail --
Od: Marián Kyral 
""
další dotaz - kde je chyba, pokud je údaj v externí databázi shodný s údaji
v OSM a přesto to POI importer nechce napárovat?

viz:
http://osm.kyralovi.cz/POI-Importer-testing/#map=17/49.1936/16.5671
=CZECPbox=hideCompletePOI
https://www.openstreetmap.org/node/4782741021
"



POI-Importer má nastaveno, jak daleko má ty schránky hledat. Tahle je moc
daleko. Spáruje se až po aktualizaci souřadnic schránek z OSM. To ale zatím
nemám automatizováno a teď jsem na to dva dny neměl čas :-(





Ale je trochu zvláštní, že ani po mnoha hodinách není na mapě vykreslena
ikona schránky. Přitom místa je tam dost.




Marián

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