[OSM-talk] Fwd: Short ways added to substitute barriers

[Jem]

Re: https://www.openstreetmap.org/way/634085262 and several more like it in
the area.

It seems that new, short ways have been introduced to replicate the purpose
of the existing barrier nodes. i.e. to prevent routing for vehicular
traffic. I believe it is incorrect and just adds complexity.

I plan to contact the user to discuss, but want to make sure I'm right. Can
any experienced members please advise?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-ja] place=city_block

[ISHIKAWA Takayuki]

こんにちは、奈良の石川です。あまり ML を頻繁に読んでいなくて投稿が遅くなりすみません。

 On Thursday, October 11, 2018, 4:25:57 PM GMT+9, Satoshi IIDA 
 wrote: 
>■admin_level=11について
>> 町内会や自治体の活動範囲はplaceの範囲と一致するのか、町内会や自治体が存在しない地域にadmin_levelを付与してよいのか
>確かにそうですね。
>町内会や自治体の範囲については、administrative boundaryとは別のエリア表現のほうがよいのかもしれません。
>（一丁目、二丁目、三丁目をあわせて1つの町内会、とかも理論的には有り得そう）

個人情報を晒したくないので個別の反例はここに書きませんが、例えば私が住んでいる場所の町内会は admin_level=10 を2つ含んでいます 
(しかも、2つを完全に含むのではなく、部分的です)。更には、私の実家の場所の町内会は、私が住んでいたころは admin_level=9 
を2つ、admin_level=10 を15個～20個くらい含んでいたように記憶しています 
(周囲の町内会もこんな感じで、1つの町内会に1000世帯以上が加入しているのが一般的でした)。なので、いいださんの指摘通り、そもそも行政的地割とは整合的ではありません。

そもそも、町内会や自治会は任意団体であり、自由に結成したり解散したり分割したり合併したりできます。市町村に登録する際に、境界が明確であることと他の登録済み町内会/自治会と地域が重複しないことが求められるのみです。

ですので、町内会や自治会を基に admin_level=11 を定めることは、私は反対です。法的な定め自体がないので、町内会や自治会を OSM 
に記載することも望ましくないと考えています (実際には認可地縁団体の申請条件の一部が町内会や自治会の定義と言えなくもないですが)。

-- 
石川
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] [Tagging-fr] Vote ouvert pour la carto des réseaux télécoms

[François Lacombe]

Bonsoir à tous,

Hier se terminait le vote sur cette proposition, première du cru pour la
cartographie des réseaux télécoms
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Telecom_local_loop

27 oui pour aucun non marquent un consensus assez fort.
Les français n'ont pas été les seuls à voter, puisque selon le wiki c'est 7
pays différents qui ont été représentés.

Merci à tous ceux qui ont pris le temps de donner leur avis, on va pouvoir
mettre à jour la doc désormais.

Bonne soirée

François

Le lun. 15 oct. 2018 à 22:55, Jean-Marc Liotier  a écrit :

> On 10/15/18 6:01 PM, François Lacombe wrote:
> > Ceci dit, en donnant assez de visibilité à nos activités, peut-être
> > que les opérateurs seront motivés et comprendront le sens de tout ça,
> > à suivre !
>
> On peut toujours rêver...
>
> Ceci dit, je suppose que la mention de GraceTHD dans ta présentation
> n'est pas innocente: s'il y a un espoir, il est du côté des
> collectivités locales, dont les intérêts ont des chances de finir par
> s'aligner sur un fonctionnement collaboratif.
>
> J'imagine bien, pour les échanges inter-opérateurs, l'intérêt politique
> des collectivités locales d'avoir comme *_codeext un objet commun,
> neutre à tous points de vue et géré collectivement, au lieu d'utiliser
> les identifiants internes de $opérateur1, $opérateur2. Peut-être un
> montage analogue à la BAN ?
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] kosmtik + requête PostGIS exploitant une relation = ERROR

[Maël REBOUX]

Bon.

J’ai tout remis à plat pour repenser le truc et parti de la table 
planet_osm_point pour que kosmtik / mapnik se concentre sur cette table.
Et ça donne la grosse requête avec x sous-requêtes ci-dessous.

Ça fonctionne très bien sur un dump Bretagne (administrative) et sous kosmtik.
\o/

Mais quand je teste avec kosmtik sur le serveur qui est branché sur la base OSM 
monde,
j’obtiens un méchant «  Postgis Plugin: ERREUR:  syntaxe en entrée invalide 
pour l'entier : «  » in getAsyncResult  » 

Je ne sais pas encore pourquoi…



-- admin_places
-- on part de la table planet_osm_point qui contient la géométrie
-- et on fait une jointure sur
--   la jointure de la requête sans doublons avec la requête avec doublons MAIS 
admin_level
SELECT
p.osm_id, p.way, COALESCE(p.tags -> 'name:br'::text,'???') as name, p.place 
as type,
sub_admin.admin_level, sub_admin.admin_name
FROM planet_osm_point AS p
JOIN
(
SELECT sub_unique.admin_centre_id, sub_unique.admin_level, 
sub_duplicate.admin_name
FROM
(
-- table sans les niveaux dupliqués : on garde le plus élevé
SELECT
  sub1.admin_centre_id, MAX(sub1.admin_level) AS admin_level
FROM
(
-- table avec tous les niveaux administratifs cumulés 
-- préfectures
SELECT
  substring((regexp_matches(members::text, 'n[0-9]*')::text) from 3 
for (char_length(regexp_matches(members::text, 'n[0-9]*')::text))-3)::bigint as 
admin_centre_id,
  '4' as admin_level
FROM planet_osm_rels WHERE tags::text ~ 'admin_level,6'
UNION
-- sous-préfectures
SELECT
  substring((regexp_matches(members::text, 'n[0-9]*')::text) from 3 
for (char_length(regexp_matches(members::text, 'n[0-9]*')::text))-3)::bigint as 
admin_centre_id,
  '3' as admin_level
FROM planet_osm_rels WHERE tags::text ~ 'admin_level,7'
UNION
-- chefs-lieux de canton
SELECT
  substring((regexp_matches(members::text, 'n[0-9]*')::text) from 3 
for (char_length(regexp_matches(members::text, 'n[0-9]*')::text))-3)::bigint as 
admin_centre_id,
  '2' as admin_level
FROM planet_osm_rels WHERE tags::text ~ 'political_division,canton'
UNION
-- communes
SELECT
  substring((regexp_matches(members::text, 'n[0-9]*')::text) from 3 
for (char_length(regexp_matches(members::text, 'n[0-9]*')::text))-3)::bigint as 
admin_centre_id,
  '1' as admin_level
FROM planet_osm_rels WHERE tags::text ~ 'admin_level,8'
) AS sub1 
GROUP BY sub1.admin_centre_id
) AS sub_unique
LEFT JOIN
(
SELECT 
sub2.admin_centre_id, sub2.admin_level, sub2.admin_name
FROM
(
-- table avec tous les niveaux administratifs cumulés 
-- préfectures
SELECT
  substring((regexp_matches(members::text, 'n[0-9]*')::text) from 3 
for (char_length(regexp_matches(members::text, 'n[0-9]*')::text))-3)::bigint as 
admin_centre_id,
  '4' as admin_level,
  'préfecture' as admin_name
FROM planet_osm_rels WHERE tags::text ~ 'admin_level,6'
UNION
-- sous-préfectures
SELECT
  substring((regexp_matches(members::text, 'n[0-9]*')::text) from 3 
for (char_length(regexp_matches(members::text, 'n[0-9]*')::text))-3)::bigint as 
admin_centre_id,
  '3' as admin_level,
  'sous-préfecture' as admin_name
FROM planet_osm_rels WHERE tags::text ~ 'admin_level,7'
UNION
-- chefs-lieux de canton
SELECT
  substring((regexp_matches(members::text, 'n[0-9]*')::text) from 3 
for (char_length(regexp_matches(members::text, 'n[0-9]*')::text))-3)::bigint as 
admin_centre_id,
  '2' as admin_level,
  'chef-lieu de canton' as admin_name
FROM planet_osm_rels WHERE tags::text ~ 'political_division,canton'
UNION
-- communes
SELECT
  substring((regexp_matches(members::text, 'n[0-9]*')::text) from 3 
for (char_length(regexp_matches(members::text, 'n[0-9]*')::text))-3)::bigint as 
admin_centre_id,
  '1' as admin_level,
  'commune' as admin_name
FROM planet_osm_rels WHERE tags::text ~ 'admin_level,8'
) AS sub2
) AS sub_duplicate
-- le critère de jointure
ON sub_unique.admin_centre_id = sub_duplicate.admin_centre_id AND 
sub_unique.admin_level = sub_duplicate.admin_level
) AS sub_admin
ON p.osm_id = sub_admin.admin_centre_id





> Le 8 oct. 2018 à 22:10, Maël REBOUX  a écrit :
> 
> Je n’ai toujours pas trouver de solutions malgré différents essais.
> J’aimerai éviter de créer une table en dur compliquée à maintenir à jour.
> 
> 
>> Le 28 sept. 2018 à 08:09, Maël REBOUX > 

[Talk-us] North Central Texas Microsoft Building Import

[Andrew]

Hello mailing list-

This message is to give the community a heads-up that users in the
Dallas-Fort Worth area are beginning an import of the Microsoft Building
Footprints for the North Central Texas area.

This is a relatively simple import that will bring approximately 1.5
million building footprints to the 14-county metro area before moving on to
outlying rural counties that don't receive much attention.

You can find more information at the wiki article here:
https://wiki.openstreetmap.org/wiki/Microsoft_Building_Import_-_North_Central_Texas

Thanks,

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

Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial

[Peter Krauss]

Olá, que bom, está avançando!
hum... Parece que houve boa intensão e disposição de fazer a coisa certa,
mas por hora meu entendimento é que ainda não expressou o que foi
solicitado. A frase* "Em complemento, concordamos com a disponibilização
dos dados de mapeamento do IPPUC sob os termos da liença ODC Open Database
License"* infelizmente não consta no texto assinado.

Sugiro fortemente que se produza um novo documento seguindo o *modelo
de Declaração de licenciamento ODbL
*
Ideal é depois registrar num cartório eletrônico oficial, tal como este
(se reclamarem eu pago!) 

- - -
PS: é muito importante conscientizar os titulares de direitos sobre os
dados abertos de interesse da OSM Brasil...  A abertura efetiva e sem
riscos para o OSM depende da declaração de licença ODbL ou declaração de
dedicação ao domínio público (CC0), e não existe outra opção simples e
segura, são apenas estas duas:
* Declaração de licenciamento CC0

* Declaração de licenciamento ODbL




On Fri, Oct 26, 2018 at 10:32 PM santamariense  wrote:

> Olá pessoal,
>
> Conseguiu-se autorização formal do Instituto de Pesquisa e
> Planejamento Urbano de Curitiba quanto a cedência dos dados de
> cartografia para o OSM disponibilizados em
> http://ippuc.org.br/geodownloads/geo.htm e a declaração está
> disponível em
> https://wiki.openstreetmap.org/wiki/File:Declara%C3%A7%C3%A3o_de_Ced%C3%AAncia_de_dados_IPPUC.pdf
>
> Gostaria que analisassem a declaração e dessem um feedback, caso
> alguém discorde que sim, está suficientemente claro que os dados podem
> ser importados para o OSM.
>
> A ideia principal, e para isso estou sendo incumbido, é importar a
> numeração predial da cidade que está disponível em "Lotes -
> (julho/2018)". Não é disponível o shapefile de prédios, mas sim dos
> lotes. A proposta é transformar a área do lote em ponto no centroide
> do seu respectivo lote, e realocar cada um dos pontos gerados para a
> proximidade da rua onde o endereço está localizado, ou seja, dentro do
> prédio, porém, mais próximo de onde provavelmente esteja a porta de
> entrada dele.
>
> Conforme as boas práticas, será mantido o histórico dos endereços já
> mapeados no OSM, inclusive suas coordenadas, sem haver duplicação de
> objetos na base de dados do OSM.
>
> A documentação está sendo feita em
> https://wiki.openstreetmap.org/wiki/Curitiba/Importa%C3%A7%C3%A3o_IPPUC
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-es] Zona centro de Madrid tageada como parque

[Jesús Gómez Fernández]

Yo añadiría boundary=low_emission_zone [1] y por supuesto quitaba
leisure=park.
En la wiki hay descrito también un esquema que se sigue para ciudades como
Londres o Estocolmo pero pienso que se ajusta menos al caso de Madrid. [2]

[1] https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dlow_emission_zone
[2] https://wiki.openstreetmap.org/wiki/London_Congestion_Charge



El dom., 28 oct. 2018 a las 18:01, A A ()
escribió:

> Hola a todos. He visto que un usuario ha tageado la zona central de Madrid
> como parque. Por lo que ha puesto como nombre deduzco que lo ha hecho por
> la nueva ordenanza de tráfico por la cual el acceso con coche está
> restringido, supongo que este área está mal tageada, aunque no sé cómo
> debería de reflejarse la nueva restricción de tráfico en OSM.
>
>
>
> El área en cuestión es
> https://www.openstreetmap.org/way/618628405#map=15/40.4177/-3.6948
>
>
> ___
> 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] Zona centro de Madrid tageada como parque

[A A]

Hola a todos. He visto que un usuario ha tageado la zona central de Madrid como 
parque. Por lo que ha puesto como nombre deduzco que lo ha hecho por la nueva 
ordenanza de tráfico por la cual el acceso con coche está restringido, supongo 
que este área está mal tageada, aunque no sé cómo debería de reflejarse la 
nueva restricción de tráfico en OSM.

El área en cuestión es 
https://www.openstreetmap.org/way/618628405#map=15/40.4177/-3.6948

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

Re: [Talk-es] Necesidad de poner límites en ciudad.

[yo paseopor]

Buenas

¡Gente!

Soy el primero que se lo deja todo al debatir y soy el primero que no tiene
miedo a ninguna edición, aunque me lluevan palos. Pero por favor haya calma
y respeto.

Sin inmiscuirme en lo que os habeis dicho previamente, la lista no es
consciente de lo que habeis hablado antes y mucho menos el tono. Así que
como persona externa a esta discusión os pediría que, con tiempo y sin
prisa los dos diérais vuestras motivaciones y las confrontarais con datos y
, sobretodo, con respeto. Creo que en esta comunidad nadie es mejor que
nadie y por lo tanto ninguna edición está por sobre de otra. Hablémoslo.
Veamos cuales son las ediciones y los puntos de vista, la comunidad se
expresará, y seguramente acabemos encontrando una solución de consenso.
Los dos como mapeadores sois muy necesarios para esta comunidad.
Cuando los dos esteis en condiciones de debatir (sé lo que es que un hilo
que te interesa pase mientras tú no tienes ni 3G ni tiempo para usarlo)
hacedlo, informarnos de todas vuestras acciones y podremos opinar, pero
sobretodo no os perdais el respeto pues entonces la edición en sí es una
anécdota cuando realmente debería ser lo más importante.

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

[Talk-lt] Vektorinis upių baseinų žemėlapis

[Tomas Straupis]

Sveiki

  Prieš metus buvo rodytas Lietuvos upių baseinų žemėlapis. Tai šį
kartą vektorinė jo versija „su mėnesienos efektu“ :-D

  https://blog.openmap.lt/2018/10/28/lietuvos-upiu-baseinai-ii/

-- 
Tomas

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

[Talk-in] Mapping party and theodolite making at Science Hack Day Belgaum Nov 2-4

[Arun Ganesh]

For folks near Belgaum and attending Science Hack Day India 2018
http://sciencehackday.in, lets have an OSM mapping party as a pre event to
SoTM on Nov 2.

There will also be a hacking project to design and build a DIY theodolite
that  students can use to create maps using trigonometry for those
interested in joining in as a resident hacker for all three days.

If you are attending do send me an email and we can coordinate.
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [OSM-talk-fr] Changement nom carburants Union Européenne

[marc marc]

Le 28. 10. 18 à 14:00, deuzeffe a écrit :
> Osmose, ae, manuel (HAHAHA, pardon, c'est nerveux), rien, ot'chose ?
> Que disent les autres listes européennes ?

sur tagging (la ml mondiale), je n'ai rien vu passé

>> - fuel:b7 pour le Diesel
>> - fuel:b10 pour le Diesel (grand froid) 

ce point là m'étonne (grand froid avec un B > à l'autre)
j'ai croisé une entreprie qui vend du bio-diesel 2ieme génération (fait 
à partir d'huile culinaire usagée)
et à titre de précaution, ils disent de faire moitié moitié pendant
les grands froids
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ces collectivités qui misent sur Openstreetmap et la cartographie participative

[Baptiste Jonglez]

Bonjour,

On 22-10-18, François Lacombe wrote:
> En parlant de collectivités, certains oublient d'ailleurs de respecter les
> termes de la licence.
> C'est un oubli fâcheux, parce qu'elles connaissent déjà tellement bien
> notre écosystème qu'elles peuvent se permettre de faire certains raccourcis.
> https://twitter.com/InfosReseaux/status/1054307688677564418

À noter, ça a été corrigé ("manuellement" mais c'est déjà ça) sur la
version de l'article sur le site du SDE09 :)

  http://sde09.fr/galeries/actualite/carte_deplopiement.pdf

Baptiste


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

Re: [Talk-it] Una gran bella giornata, a Cuneo!

[Alessandro Palmas]

Il 28/10/18 14:58, mbranco2 ha scritto:


..

Oltre a studenti dell'Istituto Tecnico, c'erano operatori del NUE112, 
del soccorso alpino, protezione civile, guardia di finanza... ma anche 
semplici cittadini interessati.


Ciao,
non aggiungo nulla alle parole di Marco se non una curiosità: gli 
operatori del 112 erano interessati, oltre ovviamente a numeri civici e 
altro, alla mappatura dei cimiteri e delle cabine telefoniche.


Alessandro Ale_Zena_IT

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

Re: [OSM-talk-fr] Tag Tiers-lieux, EPN, hackerspace, etc (was: Espace de coworking qui croire entre iD et le wiki OSM)

[deuzeffe]

Hello,

Plus généralement, je cherche une convention de tagging pour
- les espace publics numériques (EPN ; ex-cyberbases ?) : j'avais posé 
il y a longtemps la question sur le forum, sans avoir d'indications bien 
fermes ;
- les tiers-lieux : coworking_space ou coworking est ce qui en est le 
moins éloigné ;
- les hackerspace : il y a leisure=hackerspace qui fait le job pour 
l'instant

- les fablab : il semble que leisure=hackerspace convienne aussi

Et quand un tiers-lieux fait EPN _et_ coworking... c'est pas simple :(

C'est vraiment EPN qui me pose un pb. Mais peut-être que sur le terrain, 
ça rentre dans la catégorie woorking(-space) ?

--
deuzeffe, indécise.

On 12/10/2018 16:08, Christian Quest wrote:

office me semble plus adapté à un espace de coworking privé et amenity pour
un espace d'accès plutôt public...

Le ven. 12 oct. 2018 à 11:33, François Lacombe 
a écrit :


Bonjour Jean-Christophe,

La politique d'iD est de ne créer des presets que sur les tags les plus
utilisés.
Ceci sans tenir compte de ce qui est écrit sur le wiki (notamment pendant
les périodes de transitions ancien => nouveau tag), il faut donc suivre le
wiki.

Je n'ai pas d'avis sur le cas particulier de amenity vs office.

Bonne journée

François

Le ven. 12 oct. 2018 à 07:51, Jean-Christophe Becquet  a
écrit :


Bonjour,

Pour un Espace de coworking
https://www.openstreetmap.org/node/5954418134

iD me propose le tag
office=coworking

Le wiki dit
amenity=coworking_space
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcoworking_space

et office=coworking est une Page de redirection vers
amenity=coworking_space

https://wiki.openstreetmap.org/w/index.php?title=Tag:office%3Dcoworking=no

sur taginfo amenity=coworking_space (854) gagne légèrement contre
office=coworking (598).
https://taginfo.openstreetmap.org/tags/?key=amenity=coworking_space
https://taginfo.openstreetmap.org/tags/?key=office=coworking

Bref qui croire entre iD et le wiki OSM ?

Merci par avance pour vos éclaircissements

Bonne journée

JCB
--
Il y aura un retour d'expérience "Cartographies participatives avec les
habitants" par Jean-Christophe Becquet, avec pour support #OpenStreetMap.
https://twitter.com/OsmGrenoble/status/104695420100610

==APITUX : le choix du logiciel libre==

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

===




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


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





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



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

Re: [Talk-es] Necesidad de poner límites en ciudad.

[Carlos Antonio Rivera]

Todo lo que hago es un desastre y tú no entiendes nada de lo que digo y
hago por lo que se ve. Sigue con esa actitud conmigo que llegarás lejos
compañero.
Ahora estoy de viaje, a la vuelta a ver si lo dejamos todo claro.
Al menos espero que dejes de mentir o dejar de contar las cosas a tu
conveniencia. Demuestra qué tan horrible es lo que he hecho comparado con
lo que había antes, por favor.
Por supuesto que hay mucho trabajo por hacer y no todo puede hacerse
perfecto en cada edición como esperas, para eso también estamos aprendiendo
y hay gente para corregirnos.
Un saludo

El dom., 28 oct. 2018 23:10, Fco. Javier González Jiménez <
fjavier...@hotmail.com> escribió:

> Hola,
>
>
>
> Gracias yopaseopor. Veo que estamos de acuerdo en que sirvan de
> referencia para editar y no que se trasladen de forma literal. En Granada
> es un verdadero desastre lo que se ha hecho con la clasificación de las
> calles, y podemos ver casi toda la ciudad como de tercera categoría,
> bastantes de segunda y primera, y no se corresponden a una distribución
> real, ni lógica, como ya le comenté al usuario que lo hizo y que se negó a
> corregir. Para él lo que importa es lo que diga el Ayuntamiento y no lo que
> tienes delante de los ojos ni el trabajo de los que te antecedieron
> editando, o la norma de OSM de crear redes de distribución que sea:
> primarias para unir distritos, secundarías para unir barrios, terciarias
> para las vías principales dentro del barrio. Ya me diréis de qué le sirve a
> un enrutador tener que elegir entre varias calles si todas tienen la misma
> categoría…
>
>
>
> Desde luego lo ideal sería establecer los límites reales y el resto de
> características de las vías como propones en el caso de la iluminación,
> pero también de carril bici o bus, número de carriles, etcétera.
>
>
>
> Creo que cuando usamos la categoría “residencial” los enrutadores toman
> una velocidad por defecto según se indica en la ley, pero cuando usamos una
> de categoría superior, que se supone que están para usar en exteriores de
> municipios, la velocidad por defecto de los  enrutadores va en consonancia
> a la categoría, por lo que si no se pone ninguna velocidad, los enrutadores
> pueden usar 80, 90 o 100 km en mitad de la ciudad, por eso propongo, que
> más vale poner el límite genérico de 50 a no poner ninguno  en el caso de
> las vías que se les ponga una categoría superior a “residencial” únicamente
> y dentro de los municipios. Aunque legalmente todo el mundo sabe la
> velocidad en ciudad, el enrutador te puede calcular la ruta por distancia
> (ruta más corta) o velocidad (ruta más rápida), para hacer los cálculos en
> un caso se fija en la distancia, en el otro en cuanto tardas en recorrerla,
> y para eso usa los tipos de vía y límites de velocidad. Cuando no existen
> usa los que tiene puestos por defecto según el tipo de vía.
>
>
>
> Un saludo.
>
>
>
>
>
>
>
> *De:* yo paseopor 
> *Enviado el:* domingo, 28 de octubre de 2018 6:52
> *Para:* Discusión en Español de OpenStreetMap 
> *Asunto:* Re: [Talk-es] Necesidad de poner límites en ciudad.
>
>
>
> El hecho de poner un límite a las calles es útil, pero en este caso tiene
> un problema. Si especificas el límite a 50 km/h y el límite real es a 30 o
> a 40 estarás dando una información errónea. Si no especificas límite
> sabremos que esas calles las debemos de completar/revisar.
>
>
>
> La normativa de tráfico es muy clara: 50 km/h en vías urbanas. No
> necesitas un GPS que te lo especifique. Por lo tanto, con o sin datos el
> máximo en vía urbana en España (no sólo Granada) será de 50 km/h. Por lo
> que no ganas nada poniendo límites a cascoporro (porque este límite se
> sobreentiende). El 50 ya lo tienes.
>
> Sería interesante revisar la velocidad de las calles de Granada, a fin de
> poner el límite real en las calles.Aprovechad para poner la iluminación
> también si esta existiera (lit=yes)
>
>
>
> Por lo que hace referencia a las categorías poner de entrada lo que diga
> un ayuntamiento o administración sobre una vía puede fallar más que una
> escopeta de feria. Ahora bien, tener en cuenta esos datos, aprender, ver
> hacia dónde hace ir los flujos de tráfico el ayuntamiento, etc. me parece
> correcto y una forma adecuada de proceder, puesto que esos datos nos darán
> también las pistas sobre futuras actuaciones en determinadas vías
> (pacificaciones, etc.)
>
>
>
> Espero que mi opinión te haya servido :)
>
> yopaseopor
>
>
> ___
> 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] Necesidad de poner límites en ciudad.

[Fco . Javier González Jiménez]

Hola,

Gracias yopaseopor. Veo que estamos de acuerdo en que sirvan de referencia para 
editar y no que se trasladen de forma literal. En Granada es un verdadero 
desastre lo que se ha hecho con la clasificación de las calles, y podemos ver 
casi toda la ciudad como de tercera categoría, bastantes de segunda y primera, 
y no se corresponden a una distribución real, ni lógica, como ya le comenté al 
usuario que lo hizo y que se negó a corregir. Para él lo que importa es lo que 
diga el Ayuntamiento y no lo que tienes delante de los ojos ni el trabajo de 
los que te antecedieron editando, o la norma de OSM de crear redes de 
distribución que sea: primarias para unir distritos, secundarías para unir 
barrios, terciarias para las vías principales dentro del barrio. Ya me diréis 
de qué le sirve a un enrutador tener que elegir entre varias calles si todas 
tienen la misma categoría…

Desde luego lo ideal sería establecer los límites reales y el resto de 
características de las vías como propones en el caso de la iluminación, pero 
también de carril bici o bus, número de carriles, etcétera.

Creo que cuando usamos la categoría “residencial” los enrutadores toman una 
velocidad por defecto según se indica en la ley, pero cuando usamos una de 
categoría superior, que se supone que están para usar en exteriores de 
municipios, la velocidad por defecto de los  enrutadores va en consonancia a la 
categoría, por lo que si no se pone ninguna velocidad, los enrutadores pueden 
usar 80, 90 o 100 km en mitad de la ciudad, por eso propongo, que más vale 
poner el límite genérico de 50 a no poner ninguno  en el caso de las vías que 
se les ponga una categoría superior a “residencial” únicamente y dentro de los 
municipios. Aunque legalmente todo el mundo sabe la velocidad en ciudad, el 
enrutador te puede calcular la ruta por distancia (ruta más corta) o velocidad 
(ruta más rápida), para hacer los cálculos en un caso se fija en la distancia, 
en el otro en cuanto tardas en recorrerla, y para eso usa los tipos de vía y 
límites de velocidad. Cuando no existen usa los que tiene puestos por defecto 
según el tipo de vía.

Un saludo.



De: yo paseopor 
Enviado el: domingo, 28 de octubre de 2018 6:52
Para: Discusión en Español de OpenStreetMap 
Asunto: Re: [Talk-es] Necesidad de poner límites en ciudad.

El hecho de poner un límite a las calles es útil, pero en este caso tiene un 
problema. Si especificas el límite a 50 km/h y el límite real es a 30 o a 40 
estarás dando una información errónea. Si no especificas límite sabremos que 
esas calles las debemos de completar/revisar.

La normativa de tráfico es muy clara: 50 km/h en vías urbanas. No necesitas un 
GPS que te lo especifique. Por lo tanto, con o sin datos el máximo en vía 
urbana en España (no sólo Granada) será de 50 km/h. Por lo que no ganas nada 
poniendo límites a cascoporro (porque este límite se sobreentiende). El 50 ya 
lo tienes.
Sería interesante revisar la velocidad de las calles de Granada, a fin de poner 
el límite real en las calles.Aprovechad para poner la iluminación también si 
esta existiera (lit=yes)

Por lo que hace referencia a las categorías poner de entrada lo que diga un 
ayuntamiento o administración sobre una vía puede fallar más que una escopeta 
de feria. Ahora bien, tener en cuenta esos datos, aprender, ver hacia dónde 
hace ir los flujos de tráfico el ayuntamiento, etc. me parece correcto y una 
forma adecuada de proceder, puesto que esos datos nos darán también las pistas 
sobre futuras actuaciones en determinadas vías (pacificaciones, etc.)

Espero que mi opinión te haya servido :)
yopaseopor

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

[Talk-it] Una gran bella giornata, a Cuneo!

[mbranco2]

Venerdì 26 abbiamo passato una giornata full immersion su OSM: è stato
bello vedere che alle 18, dopo 9 ore, c'erano ancora una ventina di persone
che seguivano imperterrite, e abbiamo chiesto gentilmente se potevamo
andare a casa... :-)

Oltre a studenti dell'Istituto Tecnico, c'erano operatori del NUE112, del
soccorso alpino, protezione civile, guardia di finanza... ma anche semplici
cittadini interessati.

Al mattino:
- Maria Claudia Bodino ha parlato di Open Data
- Ale_zena di OSM in generale
- giovand di HOT e delle mappature umanitarie
- Fabio Tonolo di Ithaca, Copernicus e rapid mapping
- mbranco2 della comunità OSM.

Al pomeriggio workshop/jam session a oltranza, in aula con laptop e sul
campo con varie app.

Chi era interessato a proseguire il discorso ci ha lasciato la sua email,
così ora abbiamo una ML dei mappatori di zona: la useremo per organizzare
incontri periodici locali, come già facciamo in nord-piemonte ormai da più
di un anno.
Se qualcuno che legge ora è interessato, mi scriva così lo aggiungo.

Grazie Maria, Europe Direct, e Comune di Cuneo per aver organizzato questo
evento!

Marco

P.S. Qui alcune foto della giornata:
https://commons.wikimedia.org/wiki/Category:Cuneo_(IT)_:_26_October_2018
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Kevin Kofler]

Friedrich Volkmann wrote:
> Ich auch nicht, aber i.a. scheint sich die neue Rechtschreibung
> durchzusetzen (außer bei offensichtlichen Personennamen).

Keine "Göhtestraße"? ;-)

Kevin Kofler


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

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Ignorare mi sembra un peccato, il fixme, ci può stare, direi.

Penso anche che non sarebbe male "portarsi dietro" l'ID_SCHEDA, forse in una 
"note" ("note=mipaaf ID Scheda: 01/H361/VI/05" oppure, con un po' di 
creatività, "note:mipaaf_id_scheda=01/H361/VI/05")


On 2018-10-28 14:34, Cascafico Giovanni wrote:
> "Insieme omogeneo" ce ne sono (pochi) anche in fvg. Si possono ignorare o 
> desidere di aggiugere un tag p.es . fixme=redefine as polygon
>
> Il dom 28 ott 2018, 14:30 Sergio Manzi mailto:s...@smz.it>> ha 
> scritto:
>
> P.S.: Nei dati vedo "cose" che temo ci creeranno ulteriori mal di testa: 
> per esempio in un caso in Trentino vedo nella scheda un "Nome scientifico" 
> definito come "/Insieme omogeneo di Larix decidua Mill. e Picea abies (L) H. 
> Karst./". Che si fa???  :-/
>
>
> On 2018-10-28 13:25, Sergio Manzi wrote:
>>
>> Ciao Giovanni,
>>
>> scusami, hai perfettamente ragione: parlando di "/certificazione/" dei 
>> dati ho usato un termine assolutamente errato che capisco possa dare adito 
>> ad infinite discussioni. Non era mia intenzione: avrei dovuto parlare di 
>> "/affidabilità/" e in particolare intendevo riferirmi al fatto che la 
>> precisione del dato GPS per quanto riguarda l'altezza può essere molto più 
>> scadente di quella orizzontale (/ho visto coi miei occhi errori superiori ai 
>> 20m/) e che per avere un dato ragionevolmente corretto servono 
>> strumentazioni e tecniche di misura tipicamente al di fuori della nostra 
>> portata.
>>
>> ---
>>
>> Per quanto riguarda la tassonomia delle piante, neanche io sono un 
>> professionista del settore, ma mi sembra proprio che il dato (estremamente 
>> preciso) fornito dal mipaaf come "Nome scientifico" non debba essere in 
>> nessun modo deteriorato, ma vada mantenuto "tale e quale".
>>
>> "Dove" inserire questo dato può essere opinabile:
>>
>>   * escluderei "genus" perché /genus /in biologia ha un significato ben 
>> preciso, riconosciuto dal Wiki in [1], "/T//he scientific name of the *genus 
>> *for a living or fossil organism./" cioè "/Il nome scientifico del *genere 
>> *di un organismo vivente o fossile/" e con /genere /si intende "/una 
>> categoria che _raggruppa le specie_, in quanto aventi caratteristiche comuni 
>> tra loro/" [2].
>>
>>   * "species" potrebbe andare bene, visto che la definizione che ne da 
>> il Wiki è proprio "/The scientific name of the species for a living or 
>> fossil organism./" [3], "/Il nome scientifico //**della specie di un 
>> organismo vivente o fossile/" e che /specie /rappresenta il /"livello 
>> tassonomico obbligatorio gerarchicamente più basso"/ [4]. La mia sensazione, 
>> però, è che nella prassi, probabilmente a causa di un Wiki men che chiaro, 
>> si sia diffusa l'abitudine (/a mio avviso orribile/) di /spacchettare /il 
>> nome scientifico (es. Quercus robur") in genus=Qurecus + species=Robur, o, 
>> come cita il Wiki, ad errori quali "species=Oak" (/Oak è un termine Inglese, 
>> quindi non un nome scientifico, e l'equivalente latino "Quercus" è un genus 
>> , non una species/)
>>
>>   * "taxon" [5], è ampiamente meno usato di "species" e non gode dello 
>> "status: approved", ma solo di "status: in use". Il suo uso, però, mi sembra 
>> rappresenti il tentativo di mettere un po' di ordine nelle cose e 
>> soprattutto di spingere verso l'uso della nomenclatura scientifica (in 
>> latino) piuttosto che quella in Inglese. Inoltre, con le sue sotto-chiavi, 
>> permette anche (dove fosse necessario) di indicare "la precisione" con cui è 
>> stato identificato l'oggetto. Se ho certezza che un certo albero sia del 
>> genere "Quercus", ma non so identificare con esattezza di che specie si 
>> tratti, posso mettere "taxon:genus=Quercus". In un secondo tempo qualcuno 
>> più bravo di me potrà identificarlo come "Quercus robur" e aggiustare di 
>> conseguenza il taxon in "taxon=Quercus robur". Inoltre taxon permette una 
>> identificazione ancora pù precisa del livello di "specie", permettendo anche 
>> l'identificazione di varietà, cultivar, o altro ancora. Ma, mi ripeto, 
>> l'aspetto che trovo più
>> importante è che utilizzando "taxon" in qualche modo /si assicura/ 
>> che si tratti di un nome scientifico e non di un nome comune (/e da questo, 
>> poi, può derivare la possibilità di effettuare look-up per "estrarre" 
>> ulteriore informazioni, quali per esempio i nomi localizzati per le varie 
>> lingue/)
>>
>> Per questo motivo la mia proposta è di utilizzare per i nomi scientifici 
>> del dataset mipaaf la chiave "taxon".
>>
>> Ciao,
>>
>> Sergio
>>
>> ---
>>
>> [1] https://wiki.openstreetmap.org/wiki/Key:genus
>> [2] https://it.wikipedia.org/wiki/Genere_(tassonomia) 
>> 
>> [3] https://wiki.openstreetmap.org/wiki/Key:species
>> [4] https://it.wikipedia.org/wiki/Specie
>> [5] https://wiki.openstreetmap.org/wiki/Key:taxon
>>
>>
>> 

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Cascafico Giovanni]

"Insieme omogeneo" ce ne sono (pochi) anche in fvg. Si possono ignorare o
desidere di aggiugere un tag p.es. fixme=redefine as polygon

Il dom 28 ott 2018, 14:30 Sergio Manzi  ha scritto:

> P.S.: Nei dati vedo "cose" che temo ci creeranno ulteriori mal di testa:
> per esempio in un caso in Trentino vedo nella scheda un "Nome scientifico"
> definito come "*Insieme omogeneo di Larix decidua Mill. e Picea abies (L)
> H. Karst.*". Che si fa???  :-/
>
> On 2018-10-28 13:25, Sergio Manzi wrote:
>
> Ciao Giovanni,
>
> scusami, hai perfettamente ragione: parlando di "*certificazione*" dei
> dati ho usato un termine assolutamente errato che capisco possa dare adito
> ad infinite discussioni. Non era mia intenzione: avrei dovuto parlare di "
> *affidabilità*" e in particolare intendevo riferirmi al fatto che la
> precisione del dato GPS per quanto riguarda l'altezza può essere molto più
> scadente di quella orizzontale (*ho visto coi miei occhi errori superiori
> ai 20m*) e che per avere un dato ragionevolmente corretto servono
> strumentazioni e tecniche di misura tipicamente al di fuori della nostra
> portata.
>
> ---
>
> Per quanto riguarda la tassonomia delle piante, neanche io sono un
> professionista del settore, ma mi sembra proprio che il dato (estremamente
> preciso) fornito dal mipaaf come "Nome scientifico" non debba essere in
> nessun modo deteriorato, ma vada mantenuto "tale e quale".
>
> "Dove" inserire questo dato può essere opinabile:
>
>- escluderei "genus" perché *genus *in biologia ha un significato ben
>preciso, riconosciuto dal Wiki in [1], "*T**he scientific name of the
>genus for a living or fossil organism.*" cioè "*Il nome scientifico
>del genere di un organismo vivente o fossile*" e con *genere *si
>intende "*una categoria che raggruppa le specie, in quanto aventi
>caratteristiche comuni tra loro*" [2].
>
>- "species" potrebbe andare bene, visto che la definizione che ne da
>il Wiki è proprio "*The scientific name of the species for a living or
>fossil organism.*" [3], "*Il nome scientifico ** della specie di un
>organismo vivente o fossile*" e che *specie *rappresenta il *"livello
>tassonomico obbligatorio gerarchicamente più basso"* [4]. La mia
>sensazione, però, è che nella prassi, probabilmente a causa di un Wiki men
>che chiaro, si sia diffusa l'abitudine (*a mio avviso orribile*) di 
> *spacchettare
>*il nome scientifico (es. Quercus robur") in genus=Qurecus +
>species=Robur, o, come cita il Wiki, ad errori quali "species=Oak" (*Oak
>è un termine Inglese, quindi non un nome scientifico, e l'equivalente
>latino "Quercus" è un genus , non una species*)
>
>- "taxon" [5], è ampiamente meno usato di "species" e non gode dello
>"status: approved", ma solo di "status: in use". Il suo uso, però, mi
>sembra rappresenti il tentativo di mettere un po' di ordine nelle cose e
>soprattutto di spingere verso l'uso della nomenclatura scientifica (in
>latino) piuttosto che quella in Inglese. Inoltre, con le sue sotto-chiavi,
>permette anche (dove fosse necessario) di indicare "la precisione" con cui
>è stato identificato l'oggetto. Se ho certezza che un certo albero sia del
>genere "Quercus", ma non so identificare con esattezza di che specie si
>tratti, posso mettere "taxon:genus=Quercus". In un secondo tempo qualcuno
>più bravo di me potrà identificarlo come "Quercus robur" e aggiustare di
>conseguenza il taxon in "taxon=Quercus robur". Inoltre taxon permette una
>identificazione ancora pù precisa del livello di "specie", permettendo
>anche l'identificazione di varietà, cultivar, o altro ancora. Ma, mi
>ripeto, l'aspetto che trovo più importante è che utilizzando "taxon" in
>qualche modo *si assicura* che si tratti di un nome scientifico e non
>di un nome comune (*e da questo, poi, può derivare la possibilità di
>effettuare look-up per "estrarre" ulteriore informazioni, quali per esempio
>i nomi localizzati per le varie lingue*)
>
> Per questo motivo la mia proposta è di utilizzare per i nomi scientifici
> del dataset mipaaf la chiave "taxon".
>
> Ciao,
>
> Sergio
>
> ---
> [1] https://wiki.openstreetmap.org/wiki/Key:genus
> [2] https://it.wikipedia.org/wiki/Genere_(tassonomia)
> [3] https://wiki.openstreetmap.org/wiki/Key:species
> [4] https://it.wikipedia.org/wiki/Specie
> [5] https://wiki.openstreetmap.org/wiki/Key:taxon
>
>
> On 2018-10-27 17:03, Cascafico Giovanni wrote:
>
> Il mio dubbio riguardo al dato "ele" è se (*non so...*) venga sempre
>> visualizzato sulla mappa quando presente.
>>
>
> No, mi pare non sia visualizzato nemmeno se è l'unico tag.
>
> Inoltre, forse, è preferibile utilizzare questo dato solo quando sia
>> certificato (*parliamo comunque di certezza umana...*), come nel caso
>> dell'altezza delle montagne o degli aeroporti.
>>
>
> Personalmente ho aggiunto diversi valori ele ricavati dai dati exif delle
> mie foto. Comunque un'occhiata 

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

P.S.: Nei dati vedo "cose" che temo ci creeranno ulteriori mal di testa: per 
esempio in un caso in Trentino vedo nella scheda un "Nome scientifico" definito 
come "/Insieme omogeneo di Larix decidua Mill. e Picea abies (L) H. Karst./". 
Che si fa???  :-/


On 2018-10-28 13:25, Sergio Manzi wrote:
>
> Ciao Giovanni,
>
> scusami, hai perfettamente ragione: parlando di "/certificazione/" dei dati 
> ho usato un termine assolutamente errato che capisco possa dare adito ad 
> infinite discussioni. Non era mia intenzione: avrei dovuto parlare di 
> "/affidabilità/" e in particolare intendevo riferirmi al fatto che la 
> precisione del dato GPS per quanto riguarda l'altezza può essere molto più 
> scadente di quella orizzontale (/ho visto coi miei occhi errori superiori ai 
> 20m/) e che per avere un dato ragionevolmente corretto servono strumentazioni 
> e tecniche di misura tipicamente al di fuori della nostra portata.
>
> ---
>
> Per quanto riguarda la tassonomia delle piante, neanche io sono un 
> professionista del settore, ma mi sembra proprio che il dato (estremamente 
> preciso) fornito dal mipaaf come "Nome scientifico" non debba essere in 
> nessun modo deteriorato, ma vada mantenuto "tale e quale".
>
> "Dove" inserire questo dato può essere opinabile:
>
>   * escluderei "genus" perché /genus /in biologia ha un significato ben 
> preciso, riconosciuto dal Wiki in [1], "/T//he scientific name of the *genus 
> *for a living or fossil organism./" cioè "/Il nome scientifico del *genere 
> *di un organismo vivente o fossile/" e con /genere /si intende "/una 
> categoria che _raggruppa le specie_, in quanto aventi caratteristiche comuni 
> tra loro/" [2].
>
>   * "species" potrebbe andare bene, visto che la definizione che ne da il 
> Wiki è proprio "/The scientific name of the species for a living or fossil 
> organism./" [3], "/Il nome scientifico //**della specie di un organismo 
> vivente o fossile/" e che /specie /rappresenta il /"livello tassonomico 
> obbligatorio gerarchicamente più basso"/ [4]. La mia sensazione, però, è che 
> nella prassi, probabilmente a causa di un Wiki men che chiaro, si sia diffusa 
> l'abitudine (/a mio avviso orribile/) di /spacchettare /il nome scientifico 
> (es. Quercus robur") in genus=Qurecus + species=Robur, o, come cita il Wiki, 
> ad errori quali "species=Oak" (/Oak è un termine Inglese, quindi non un nome 
> scientifico, e l'equivalente latino "Quercus" è un genus , non una species/)
>
>   * "taxon" [5], è ampiamente meno usato di "species" e non gode dello 
> "status: approved", ma solo di "status: in use". Il suo uso, però, mi sembra 
> rappresenti il tentativo di mettere un po' di ordine nelle cose e soprattutto 
> di spingere verso l'uso della nomenclatura scientifica (in latino) piuttosto 
> che quella in Inglese. Inoltre, con le sue sotto-chiavi, permette anche (dove 
> fosse necessario) di indicare "la precisione" con cui è stato identificato 
> l'oggetto. Se ho certezza che un certo albero sia del genere "Quercus", ma 
> non so identificare con esattezza di che specie si tratti, posso mettere 
> "taxon:genus=Quercus". In un secondo tempo qualcuno più bravo di me potrà 
> identificarlo come "Quercus robur" e aggiustare di conseguenza il taxon in 
> "taxon=Quercus robur". Inoltre taxon permette una identificazione ancora pù 
> precisa del livello di "specie", permettendo anche l'identificazione di 
> varietà, cultivar, o altro ancora. Ma, mi ripeto, l'aspetto che trovo più 
> importante è
> che utilizzando "taxon" in qualche modo /si assicura/ che si tratti di un 
> nome scientifico e non di un nome comune (/e da questo, poi, può derivare la 
> possibilità di effettuare look-up per "estrarre" ulteriore informazioni, 
> quali per esempio i nomi localizzati per le varie lingue/)
>
> Per questo motivo la mia proposta è di utilizzare per i nomi scientifici del 
> dataset mipaaf la chiave "taxon".
>
> Ciao,
>
> Sergio
>
> ---
>
> [1] https://wiki.openstreetmap.org/wiki/Key:genus
> [2] https://it.wikipedia.org/wiki/Genere_(tassonomia)
> [3] https://wiki.openstreetmap.org/wiki/Key:species
> [4] https://it.wikipedia.org/wiki/Specie
> [5] https://wiki.openstreetmap.org/wiki/Key:taxon
>
>
> On 2018-10-27 17:03, Cascafico Giovanni wrote:
>>
>> Il mio dubbio riguardo al dato "ele" è se (/non so.../) venga sempre 
>> visualizzato sulla mappa quando presente.
>>
>>
>> No, mi pare non sia visualizzato nemmeno se è l'unico tag.
>>
>> Inoltre, forse, è preferibile utilizzare questo dato solo quando sia 
>> certificato (/parliamo comunque di certezza umana.../), come nel caso 
>> dell'altezza delle montagne o degli aeroporti.
>>
>>
>> Personalmente ho aggiunto diversi valori ele ricavati dai dati exif delle 
>> mie foto. Comunque un'occhiata a campione fa sempre bene.
>>
>>  Il discorso della certificazione sconvolgerebbe tutto 
>> osm se fosse applicato: chi ha l'autorità di certificare? quali sono le 
>> priorità per certificare? quali sono le tolleranze? 

Re: [Talk-it] quale barrier?

[Samuele Battarra]

In data sabato 27 ottobre 2018 22:03:58 CET, demon.box ha scritto:
> ciao, spesso mi imbatto in questo tipo di rozza barriera fatta di grossi
> rami, messa volutamente per disincentivare il passaggio per lo meno di moto
> e mtb, come taggarlo?

quello che si avvicina di più è barrier=log

-- 
Samuele Battarra
batta...@email.it

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

Re: [OSM-talk-fr] Changement nom carburants Union Européenne

[deuzeffe]

On fait quoi, pour ça ?

Osmose, ae, manuel (HAHAHA, pardon, c'est nerveux), rien, ot'chose ?
Que disent les autres listes européennes ?
--
deuzeffe, qui purge sa pile de mail.

On 10/10/2018 16:25, SALLES Quentin wrote:

Bonjour,

A partir du vendredi 12 octobre, le nom des carburants (ex : Sans Plomb 98,
Sans Plomb 95, Sans Plomb 95-E10, Diesel, etc) va changer en France et dans
l'Union Européenne suite à un nouveau décret voté en 2014 dans le but
d'avoir une harmonisation totale entre les pays.
Je vous mets à disposition un article que j'ai pris de France Bleu Loiret :
https://www.francebleu.fr/infos/transports/le-loiret-se-prepare-au-changement-de-nom-des-carburants-1538810129

Actuellement, les différentes clés sont les suivantes :
- fuel:octane_95 : Sans Plomb 95
- fuel:octane_98 : Sans Plomb 98
- fuel:e10 : Sans Plomb 95-E10
- fuel:diesel : Diesel
- etc

Avec la nouvelle réforme européenne, cela pourrait devenir :
- fuel:e5 pour les Sans Plomb 95 et 98
- fuel:e10 pour le Sans Plomb 95-E10
- fuel:e85 pour l'Ethanol
- fuel:b7 pour le Diesel
- fuel:b10 pour le Diesel (grand froid)
- etc...

Je voudrais savoir si on partait ou non sur cette nouvelle classification
et également en parler sur la liste internationale.

Quentin SALLES


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



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

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Ciao Giovanni,

scusami, hai perfettamente ragione: parlando di "/certificazione/" dei dati ho 
usato un termine assolutamente errato che capisco possa dare adito ad infinite 
discussioni. Non era mia intenzione: avrei dovuto parlare di "/affidabilità/" e 
in particolare intendevo riferirmi al fatto che la precisione del dato GPS per 
quanto riguarda l'altezza può essere molto più scadente di quella orizzontale 
(/ho visto coi miei occhi errori superiori ai 20m/) e che per avere un dato 
ragionevolmente corretto servono strumentazioni e tecniche di misura 
tipicamente al di fuori della nostra portata.

---

Per quanto riguarda la tassonomia delle piante, neanche io sono un 
professionista del settore, ma mi sembra proprio che il dato (estremamente 
preciso) fornito dal mipaaf come "Nome scientifico" non debba essere in nessun 
modo deteriorato, ma vada mantenuto "tale e quale".

"Dove" inserire questo dato può essere opinabile:

  * escluderei "genus" perché /genus /in biologia ha un significato ben 
preciso, riconosciuto dal Wiki in [1], "/T//he scientific name of the *genus 
*for a living or fossil organism./" cioè "/Il nome scientifico del *genere *di 
un organismo vivente o fossile/" e con /genere /si intende "/una categoria che 
_raggruppa le specie_, in quanto aventi caratteristiche comuni tra loro/" [2].

  * "species" potrebbe andare bene, visto che la definizione che ne da il Wiki 
è proprio "/The scientific name of the species for a living or fossil 
organism./" [3], "/Il nome scientifico //**della specie di un organismo vivente 
o fossile/" e che /specie /rappresenta il /"livello tassonomico obbligatorio 
gerarchicamente più basso"/ [4]. La mia sensazione, però, è che nella prassi, 
probabilmente a causa di un Wiki men che chiaro, si sia diffusa l'abitudine (/a 
mio avviso orribile/) di /spacchettare /il nome scientifico (es. Quercus 
robur") in genus=Qurecus + species=Robur, o, come cita il Wiki, ad errori quali 
"species=Oak" (/Oak è un termine Inglese, quindi non un nome scientifico, e 
l'equivalente latino "Quercus" è un genus , non una species/)

  * "taxon" [5], è ampiamente meno usato di "species" e non gode dello "status: 
approved", ma solo di "status: in use". Il suo uso, però, mi sembra rappresenti 
il tentativo di mettere un po' di ordine nelle cose e soprattutto di spingere 
verso l'uso della nomenclatura scientifica (in latino) piuttosto che quella in 
Inglese. Inoltre, con le sue sotto-chiavi, permette anche (dove fosse 
necessario) di indicare "la precisione" con cui è stato identificato l'oggetto. 
Se ho certezza che un certo albero sia del genere "Quercus", ma non so 
identificare con esattezza di che specie si tratti, posso mettere 
"taxon:genus=Quercus". In un secondo tempo qualcuno più bravo di me potrà 
identificarlo come "Quercus robur" e aggiustare di conseguenza il taxon in 
"taxon=Quercus robur". Inoltre taxon permette una identificazione ancora pù 
precisa del livello di "specie", permettendo anche l'identificazione di 
varietà, cultivar, o altro ancora. Ma, mi ripeto, l'aspetto che trovo più 
importante è
che utilizzando "taxon" in qualche modo /si assicura/ che si tratti di un 
nome scientifico e non di un nome comune (/e da questo, poi, può derivare la 
possibilità di effettuare look-up per "estrarre" ulteriore informazioni, quali 
per esempio i nomi localizzati per le varie lingue/)

Per questo motivo la mia proposta è di utilizzare per i nomi scientifici del 
dataset mipaaf la chiave "taxon".

Ciao,

Sergio

---

[1] https://wiki.openstreetmap.org/wiki/Key:genus
[2] https://it.wikipedia.org/wiki/Genere_(tassonomia)
[3] https://wiki.openstreetmap.org/wiki/Key:species
[4] https://it.wikipedia.org/wiki/Specie
[5] https://wiki.openstreetmap.org/wiki/Key:taxon


On 2018-10-27 17:03, Cascafico Giovanni wrote:
>
> Il mio dubbio riguardo al dato "ele" è se (/non so.../) venga sempre 
> visualizzato sulla mappa quando presente.
>
>
> No, mi pare non sia visualizzato nemmeno se è l'unico tag.
>
> Inoltre, forse, è preferibile utilizzare questo dato solo quando sia 
> certificato (/parliamo comunque di certezza umana.../), come nel caso 
> dell'altezza delle montagne o degli aeroporti.
>
>
> Personalmente ho aggiunto diversi valori ele ricavati dai dati exif delle mie 
> foto. Comunque un'occhiata a campione fa sempre bene.
>
>  Il discorso della certificazione sconvolgerebbe tutto 
> osm se fosse applicato: chi ha l'autorità di certificare? quali sono le 
> priorità per certificare? quali sono le tolleranze? L'approccio e la 
> peculiarità osm sono proprio nel non avere un'autorità centrale. Che ciascuno 
> possa essere creatore e controllore finora ha dato risultati non male, non 
> credi?
>
> Personalmente faccio (/fortemente/) il tifo per "taxon" che riunisce in 
> se i due termini (Genus + species) della classificazione binomiale [1] (es: 
> "Pinus nigra") e che si presta ad ulteriori specificazioni (es. "/Pinus 
> nigra/ var. /austriaca/")
>
>
> Sono 

Re: [Talk-es] Propuesta de cambios en la normalización para España de carreteras nacionales

[Rafael Avila Coya]

Hola, yopaseopor:

Espero que no me incluyas en eso de "vehemente", criterio en todo caso 
subjetivo ;)


No veo ningún problema en que diferentes N-XXX tengan diferente 
clasificación (unas trunk y otras primary). Eso quizás se puede 
documentar con criterios más o menos objetivos de importancia de la vía.


Lo que creo que no es buena práctica es usar datos tipo IMDs para 
decidirse por uno u otro valor (además de necesitarse permiso del 
propietario para usarlos).


En cambio, a parte de utilizar la importancia de las poblaciones que 
conecta, quizás se puede añadir, para el caso de trunk vs. primary, las 
características que pones en la wiki del enlace.


Una misma carretera no debe tener diferentes categorías (valor de 
highway) durante su recorrido entre dos o más poblaciones, pero esto no 
implica que una N-XXX tenga que tener la misma categoría durante toda su 
extensión, aunque habrá que justificar bien el cambio de categoría para 
cada caso.


Saludos,

Rafael.

O 27/10/18 ás 18:40, yo paseopor escribiu:


Hola

Lo que hecho en falta es una propuesta clara y a ser posible concisa y
en la wiki. Y que valga para toda España.


Creo que una propuesta como esta, más o menos parecida, con más o menos 
parámetros, pero con la misma intencionalidad la he escrito en esta 
lista mínimo 6 veces. Todas ellas han tenido ,al final de una 
correspondencia bastante intensa, una oposición vehemente especialmente 
por parte de algunos miembros de la comunidad lo cual ha hecho que la 
gran mayoría de datos, de observaciones y de desarrollos de la propuesta 
se quede en agua de borrajas.


En algunas de las anteriores propuestas se ha hecho trabajo también con 
la wiki, de hecho existen algunas de esas páginas como por ejemplo

[1].
Incluso se ha conseguido la categorización en otras vías que no fueren 
de Fomento por parte de la comunidad OSM de algunas autonomías.


Te puedo contar que personalmente yo creo en esta propuesta , por ello 
de la propuesta en la wiki tengo un esbozo. Pero también te puedo decir 
que dado el resultado de las últimas 5 veces no la he perfilado del todo 
en la wiki...para que después no se apruebe. La he explicado en lista 
extensamente (y no es la primera vez que lo hago) y sólo le faltan 
detalles por configurar y acabar de ajustar.


-La propuesta vale para toda España (un IMD provincial tiene el mismo 
significado aquí que en Murcia, y por supuesto vale para cualquier 
administración)
-La propuesta es concisa: usar los estudios de tráfico de Fomento (IMD, 
velocidad media, características de la vía) para determinar si las 
carreteras de Fomento deben seguir siendo trunk, especialmente aquellas 
que tienen una alternativa libre de pago de doble plataforma como 
recorrido paralelo.


Saludos
yopaseopor

[1] https://wiki.openstreetmap.org/wiki/ES:Normalizaci%C3%B3n_f%C3%ADsica

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



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

Re: [Talk-it] hotel che è anche ristorante

[Volker Schmidt]

> puoi fare due nodi ...
>

... solo se sono due porte con due civici diversi (o sbaglio?)
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-es] Propuesta de cambios en la normalización para España de carreteras nacionales

[Rafael Avila Coya]

Hola, Santiago:

Un vial debe mantener, por regla general, el mismo valor de la etiqueta 
highway durante todo el recorrido, sea el estado que sea durante el 
recorrido, o su nivel de tráfico. Si una unclassified está asfaltada en 
un tramo y con grava en otro, se pone surface=asphalt en el primero y 
surface=gravel en el otro. Pero la vía completa es siempre unclassified.


Lo que hace un highway=primary por ejemplo es su importancia en la red 
viaria en su conjunto, no el estado en el que se encuentre. Y esa 
importancia se refiere a la categoría de los núcleos de población que 
conecta, no a su nivel de tráfico o estado de las carreteras. La única 
excepción son las highway=motorway, que deben cumplir ciertas 
condiciones, como los sentidos separados, etc.


Por eso puse el ejemplo de una unclassified en parte asfaltada y en otra 
parte no, y que es bastante habitual que mappers etiqueten un vial 
unclassified sin asfaltar como track, que es una categoría completamente 
diferente.


Un saludo,

Rafael.


O 27/10/18 ás 15:31, Santiago Crespo escribiu:

Hola,

Después de leer los 30 correos no puedo resistirme a dar mi opinión,
aunque nunca he editado una carretera en OSM y ni siquiera tengo el
carnet :)

Creo que tiene sentido clasificar las carreteras y los tramos por sus
cualidades físicas e importancia, en lugar de los criterios
administrativos. Ya sé que existen etiquetas para el estado físico, pero
highway=* debería reflejar la importancia que tiene una vía en relación
con otras del entorno y/o del país.

No debería importarnos que una misma carretera pase de highway=trunk a
highway=loquesea según el tramo, lo importante es representar la
realidad sobre el terreno.

Para indicar quién administra una carretera está la etiqueta operator=*
(además de ref=* para el código de referencia oficial).

Lo que hecho en falta es una propuesta clara y a ser posible concisa y
en la wiki. Y que valga para toda España.

Saludos,
Santiago Crespo

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



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

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Volker Schmidt]

> Si esegue la conflation su natural=tree e denotation!=null
>

Questo mi era chiaro

L'eventuale doppione (definito dai tag sopra ed in un certo raggio max) non
> viene importato, ma i tag considerati "master" vanno a rimpiazzare o ad
> aggiungersi al nodo preesistente.
>

Non va bene, perché in questo modo rischi di buttare via un nuovo dato
"buono", cioè la posizione di un albero monumentale da un data set (spero)
affidabile e metti i dati su una posizione "mano buona" o anche fasulla
(gli alberi del vecchio import spesso sono sparsi sul territorio a caso per
indicare "qua ci sono alberi", come si faceva una volta disegnando a mano
una mappa topografica)

Alla fine ci saranno 140,000 più una-due centinaia, ma quelli importati
> avranno un ref inequivocabile, che li distingue per il futuro disboscamento.
>

... e intanto continuano col rendere sulla mappa alberi non esistenti e fra
questi non si vedono quelli veri (mi dirai che non mappiamo per il renderer
...)

Non è così facile anche per un altro motivo: fra quelli "fasulli" del
vecchio import si nascondono anche tanti "veri" alberi.

Perché non cogliamo l'occasione del novo import per pulire la situazione
prima?

Una domanda in questo contesto: qualcuno ha controllato che non esiste un
dataset più recente di questo:
"Regione_del_Veneto_LR28_16.7.1976_Formazione_CTR_auth_39164-5700-1100_23.01.2009"
(che fra altro non riesco di trovare)

>
> Il sab 27 ott 2018, 17:42 Volker Schmidt  ha scritto:
>
>> Ci sono de aspetti che non son stati menzionati, mi sembra:
>> (1) Che cosa facciamo per capire se un albero da importare è un doppione
>> di un albero già presente in OSM
>> (2) Ci sono in OSM (nel Veneto) in qualcosa come 140 mila alberi (
>> http://overpass-turbo.eu/s/D9M)
>>
>> Il problema, già sollevato e discusso in passato a più riprese, è che il
>> tag natural=tree secondo il wiki dovrebbe essere " A single *tree*,
>> sometimes lone or significant."
>> ma è stato utilizzato per rendere più bella la mappa al posto di landuse,
>> importando in alcune zone ben limitate questi 140 mila alberi, che, in più
>> in tanti casi non corrispondono a nessun albero sul terreno.
>> Se adesso aggiungiamo alberi monumentali con lo stesso tag, facciamo la
>> confusione totale.
>> Prima dell'import dobbiamo pulire la mappa di gran èparte di questi 140
>> mila alberi "decorativi"
>>
>> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-es] Propuesta de cambios en la normalización para España de carreteras nacionales

[Jorge Sanz Sanfructuoso]

Buenas

Creo que Lanxana tiene razón que se a descentrado un poco la conversación y
pido disculpas por la parte de ello que es mi culpa.
El texto crece, crece ,crece pero al final no se resuelven las dudas y es
difícil de seguir.

Hoy por hoy la propuesta lo único que entiendo es que se cogen todos los
datos, pero después de muchas veces que se a tratado el tema sinceramente
todavía no sé como coger una carretera y cómo ponerla según el criterio que
comentas. Y es donde desde el primer mensaje se ha comentado la
subjetividad.

Creo que es bueno seguir la conversación a partir de lo que a comentado
Lanxana que es un resumen más o menos de las dudas.

1 - El tema de partir o no la vía en varias categorías a lo largo de su
trazado lo he preguntado creo que 2 veces. Creo necesaria la respuesta de
que considera la propuesta. Creo que es un punto importante.
2 - Capacidad o importancia no tiene que ver con características físicas.
Habra en casos que coincidirá, en muchos casos pero no todos, y son cosas
diferentes. Lo ideal es que coincidiera pero por desgracia no siempre es
así. Creo que por eso para temas físico hay más etiquetas. Entre capacidad
e importancia yo tiro más por importancia. Es una cosa más fija y sin menos
dudas. Eso no quita que se pueda abrir el debate algún cambio del sistema
actual.
3 - Es una cosa que creo que es muy difícil de determinar y problema grande
de poder realizar este cambio. Lo único que le veo una salida real es al
tema de la carretera paralela a una autovía. Con varias cosas que concretar
de cómo se haría exactamente pero posible. Lo demás es muy cambiante y
subjetivo según zonas. Tienes carreteras que no mejoran y conservan aunque
son importantes porque van hacer la autovía paralela. Pero a la vez la
autovía paralela tampoco llega. Y luego carreteras que a lo mejor son menos
importantes pero el arreglo es mucho más barato que una autovía nueva y sí
se ha realizado. O que llegues pases de provincia y en un lado se conserve
y en el otro no.
4 - Ahora mismo no se me ocurre más.
5 - Yo creo que no y vuelvo al punto 3 y alargo. Por desgracia en este
sentido en una mayoría de la red nacional la importancia se ha medido por
hago o no autovía, el punto medio no suele existir. Y o se ha llegado hacer
autovía o sigue como estaba la carretera hace años. Incluso dentro de las
propias autovías lo sufrimos, que al ver una autovía de hace 20 años y una
moderna no tiene nada que ver aun teniendo más importancia la de hace 20
años.
6 - Este punto no termino de entender a qué se refiere exactamente.
Normalmente creo que si hay 2 trazados tiene más importancia uno que otro.
No termino ahora de visualizar el caso al que te refieres.
7 - Yo creo que sí. Cómo he comentado por arriba la importancia no siempre
esta ligada con el resto de características. Sería lo ideal pero no es así.
Todo esto también cambia según las zonas de España, tenemos un país muy
diverso.

un saludo.



El dom., 28 oct. 2018 a las 8:30, yo paseopor ()
escribió:

> On Sat, Oct 27, 2018 at 12:54 AM Jorge Sanz Sanfructuoso <
> sanc...@gmail.com> wrote:
>
>>
>> Yo no conozco esas revisiones que comentas en todas las carreteras menos
>> en las nacionales.
>>
> -De las varias propuestas de normalización física de vías acabaron
> saliendo cambios en varias autonomías, en la lista puedes ver comentarios
> sobre la red de Canarias, Andalucía, Catalunya o Galicia entre otras. De
> todas formas, dado que esta propuesta es objetiva (usa estadísticas como
> los IMD de que disponen la mayoría de infraestructuras, sean de la
> administración que sean, así como la velocidad media) o las características
> visibles de la vía (cruces internivel, etc.) vale para cualquier
> administración y estaría de acuerdo en aplicarla en cualquier carretera de
> cualquier administración.
>
>>
>> Hay un problema muy claro en esta propuesta y que todavía no esta
>> aclarado y nunca aclaras y vas cogiendo de un sitio y de otro y no
>> concretas. Tan pronto hablas de IMD, como de cruces a nivel, velocidad
>> media, cómo algún otro parámetro. Una propuesta no puede ser una mezcla de
>> todo sin definir cómo se usa claramente. No digo que no se pueda combinar
>> todo, que puede que sí. Pero es que no concretas nada. Usa todo ¿cómo dice
>> tu propuesta que se use todo eso concretamente? de una manera que no lleve
>> a líos y ambigüedades? ¿Vamos por trocitos de carretera? ¿carreteras
>> completas? Ya varias cosas de estas te las he comentado pero son cosas
>> que si no se concretan claramente no se puede usar nada. Eso desde el
>> primer mensaje que se ha dicho que no es objetivo es el mayor problema y
>> todavía no lo he visto solucionado.
>>
>
> Desde el primer mensaje hablo de todos los aspectos de la propuesta. De
> hecho siempre los ordeno de igual forma,porque ese es el orden de criterio
> que según la propuesta se debe seguir. En caso de duda podemos usar el
> criterio inferior .Y todo ello obtenido en una medida que sea proporcional:
> Provincial.
>

Re: [Talk-es] Propuesta de cambios en la normalización para España de carreteras nacionales

[Rafael Avila Coya]

Hola:

Según entiendo por vuestros correos, los datos IMD son del Ministerio de 
Fomento, pero daría igual si fuesen de otra institución, organización o 
particular. Ese ente tiene el copyright de esos datos.


a) Si los datos del IMD se quisiesen incorporar a OSM como una nueva 
etiqueta dentro de objetos (nodos, vías, relaciones), ya fuesen objetos 
presentes en OSM u objetos de nueva creación, sería una importación.


b) Si se quisiese usar los datos de IMD para modificar etiquetas ya 
presentes de objetos de la base de datos, no sería una importación.


En ambos casos, habría que contar con el permiso del propietario de los 
datos, con licencia compatible con la ODbL.


Un saludo,

Rafael.

O 27/10/18 ás 08:31, yo paseopor escribiu:


1. Sería una importación de datos. Dudo que fuese bien recibida por la
comunidad global. A mí no me parece buena idea en principio, entre
otras
razones por la dificultad del mantenimiento.

2. Salvo que mappers se pusiesen a calcular IMD's (lo dudo muchísimo),
sería un dato sólo recabable de Fomento. Seguir importando.

Saludos,

Rafael.

1- Me gustaría aclarar que usar un dato como base para la categorización 
de otro no tengo claro que sea importación. Esto sería importante , no 
sólo para las carreteras sino para el resto de elementos del mapa.
En el caso de la propuesta la IMD de una vía enfrente de la IMD de otras 
serviría para determinar los usos que se dan de una vía en una zona 
(este sistema vale para toda administración: 1 vehículos por día son 
1 vehículos). En ningún caso se pretende importar los datos ni de 
IMD ni de velocidad media (las características físicas ya están en el mapa).


2- ¿Consultar datos es importar?
3- ¿Las dificultades de mantenimiento (todos los edificios de España, 
todas las vías de España, todas las calles de España, todos los caminos 
de España, todas las gasolineras de España...) nos deben impedir mapear 
un elemento? ¿Ese es un criterio a seguir por la comunidad? ¿La dificultad?


Saludos
yopaseopor

___
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] La app Vespucci me posiciona con mucho error. ¿Os pasa?

[Alberto Llorente]

Semanas más tarde, tras recuperar mi móvil averiado, lo he probado y,
efectivamente, poniendo en configuración del móvil como fuente única de
posicionamiento el GPS, se posiciona correctamente.

Raro porque otros programas yo creo que lo gestionan mejor, pero me sirve
perfectamente tu solución. Muchas gracias :))

El vie., 12 oct. 2018 a las 19:58, Miguel Sevilla-Callejo (<
msevill...@gmail.com>) escribió:

> Hola,
>
> A mi no me ha pasado esto de la falta de precisión de localización de
> vespucci frente a otras apps pero se me ocurre que puede estar relacionado
> con  los servicios de posicionamiento de Google del móvil (posicionamiento
> por redes wifi por ejemplo) que este programa no use por defecto o por una
> configuración particular.
>
> Yo tengo todos esos servicios "extras" deshabilitados y solo uso la señal
> GPS, que por otro lado, gracias al buen receptor de.mi aparato, parece que
> funciona con errores en campo abierto por debajo de 3m.
>
> Prueba a ver y nos comentas.
>
> Saludos
>
> On Thu, 11 Oct 2018, 14:15 Rodrigo Rega,  wrote:
>
>> Podría ser que tengas en Android el posicionamiento configurado como
>> "Ahorro de batería", pero por lo que dices tampoco me cuadra. ¿Has
>> verificado que lo tienes en "solo teléfono"?
>>
>> El jue., 11 oct. 2018 8:04, Alberto Llorente 
>> escribió:
>>
>>> La app Vespucci (
>>> https://play.google.com/store/apps/details?id=de.blau.android), al
>>> menos en mi móvil, situa la posición malísimamente. Si es asi para todo el
>>> mundo, lo veo un peligro de la repera al editar en directo.
>>>
>>> La he probado varios días y esa es mi experiencia. Cuando el GNSS me
>>> sitúa en un punto, hay errores de decenas de metros respecto a la posición
>>> real. En ese momento, consulto Orux, Ozi y Google Maps y me sitúan
>>> perfecto, con el típico error de +-3 m.
>>>
>>> ¿A alguien le pasa lo mismo?. Al final, de momento sólo me sirve para
>>> editar posicionando a mano
>>>
>>> Nunca he tenido problemas de posicionamiento con ninguna app.
>>>
>>> :)
>>> ___
>>> 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] Erreurs Osmose : rue qui débouche sur une zone piétonne

[Cédric Frayssinet]

Le 28/10/2018 à 11:43, marc marc a écrit :
> Le 28. 10. 18 à 11:20, Cédric Frayssinet a écrit :
>> /*Jonction imparfaite, joindre le nœud ou utiliser l’attribut “noexit” 
>> si sans issue*/
>>
>> http://osmose.openstreetmap.fr/fr/map/#zoom=18=43.982123=3.136746==1==
> ce n'est pas la place le soucis parce que là c'est correctement connecté
> c'est la proximité des 2 routes très proche à mon avis
> on le voit avec l'alerte au nord concernant
> https://www.openstreetmap.org/node/704359470
> à cet endroit là il manque un noexit sur ce noeud
>
> pour l'autre extrémité ou les 2 rues sont tout aussi proche,
> c'est un faux positif
> osmose gagnerait peut-être a donner le way proche
> au lieu de donner le way auquel appartient le noeud

Finalement, hormis le noexit sur ce nœud, les autres sont tous des faux
positifs si j'ai bien compris. J'avais regardé des bouts de ruelles à
proximité, ils n'avaient pas non plus de noexit...

Merci Marc.



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

Re: [OSM-talk-fr] Erreurs Osmose : rue qui débouche sur une zone piétonne

[marc marc]

Le 28. 10. 18 à 11:20, Cédric Frayssinet a écrit :
> /*Jonction imparfaite, joindre le nœud ou utiliser l’attribut “noexit” 
> si sans issue*/
> 
> http://osmose.openstreetmap.fr/fr/map/#zoom=18=43.982123=3.136746==1==

ce n'est pas la place le soucis parce que là c'est correctement connecté
c'est la proximité des 2 routes très proche à mon avis
on le voit avec l'alerte au nord concernant
https://www.openstreetmap.org/node/704359470
à cet endroit là il manque un noexit sur ce noeud

pour l'autre extrémité ou les 2 rues sont tout aussi proche,
c'est un faux positif
osmose gagnerait peut-être a donner le way proche
au lieu de donner le way auquel appartient le noeud
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] baignade interdite

[marc marc]

Le 28. 10. 18 à 08:28, osm.sanspourr...@spamgourmet.com a écrit :
> zones de baignade _interdite_.
> https://wiki.openstreetmap.org/wiki/Swimming_and_bathing

le plus clair me semble swimming=no mais peu utilisé
https://taginfo.openstreetmap.org/tags/swimming=no
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Il 26 ottobre a Cuneo una giornata dedicata ad OpenStreetMap

[mbranco2]

Hai ragione Luca, grazie della segnalazione, provvedo!

Il giorno ven 19 ott 2018 alle ore 15:08 Luca Delucchi 
ha scritto:

> On Fri, 12 Oct 2018 at 19:48, mbranco2  wrote:
> >
> > Ciao Lista,
> >
>
> Ciao,
>
> > vi informo che venerdì 26 ottobre, a Cuneo, ci sarà un incontro dedicato
> ad OSM.
> >
>
> sarebbe bello tenere storia degli eventi nelle pagine dedicate sul wiki
>
> https://wiki.openstreetmap.org/wiki/WikiProject_Italy/Events
> https://wiki.openstreetmap.org/wiki/WikiProject_Italy/PastEvents
>
> >
> > Un saluto,
> > Marco
> >
>
> --
> ciao
> Luca
>
> www.lucadelu.org
>
> ___
> 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

[OSM-talk-fr] Erreurs Osmose : rue qui débouche sur une zone piétonne

[Cédric Frayssinet]

Bonjour à tous,

Je découvre ces erreurs et je ne trouve pas vraiment pourquoi c'est en
erreur Osmose, est-ce de faux-positifs ?

/*Jonction imparfaite, joindre le nœud ou utiliser l’attribut “noexit”
si sans issue*/

http://osmose.openstreetmap.fr/fr/map/#zoom=18=43.982123=3.136746==1==

Merci !

Cédric


-- 
Dégooglisé !  - Sociétaire Enercoop
, l'énergie militante

Sur Mastodon : @bristow...@framapiaf.org 

Promouvoir et soutenir le logiciel libre 

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

Re: [Talk-it] progetti: come funziona?

[Paolo Monegato]

Il 26/10/2018 09:17, Gabriele Sani ha scritto:
Ottimo, ho abbozzato la cosa [1] e inizialmente creero' una tabella 
per ogni sezione CAI. Poi la correzione delle relazioni (che si puo' 
fare da casa) la faccio con calma, mentre per i cartelli segnavia e' 
meglio fare rilevamenti sul posto!


Grazie ancora a tutti

[1] https://wiki.openstreetmap.org/wiki/Emilia_Romagna/Sentieri



Giusto un appunto veloce: vedo che la pagina è raggiungibile solo da 
WikiProject:Italy/Sentieri e non dalla pagina dell'Emilia Romagna. 
Sarebbe da inserire il link da qualche parte.


ciao
Paolo M


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

Re: [Talk-it] quale barrier?

[Martin Koppenhoefer]

sent from a phone

> On 27. Oct 2018, at 22:03, demon.box  wrote:
> 
> ciao, spesso mi imbatto in questo tipo di rozza barriera fatta di grossi
> rami, messa volutamente per disincentivare il passaggio per lo meno di moto
> e mtb, come taggarlo?


com’è generalmente la situazione legale italiana riguardando l’accesso delle 
foreste? Devo rimanere sui percorsi oppure potrei anche andare dove non c’è? Si 
distingue tra veicoli (mtb) e pedoni?

Come barrier non so’ se abbiamo un valore pertinente, ma credo in “obstacle” ci 
sia.


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

Re: [Talk-it] hotel che è anche ristorante

[Martin Koppenhoefer]

sent from a phone

> On 27. Oct 2018, at 22:13, demon.box  wrote:
> 
> ciao, se ho un hotel che offre anche servizio come ristorante aperto a tutti,
> visto che non è detto che sia sempre così nel senso che il ristorante di un
> hotel non è detto che sia aperto anche a chi non risiede nell'hotel mi pare
> un'aspetto importante da segnalare.
> detto questo, aggiungo un altro nodo a se stante come amenity=restaurant
> oppure sullo stesso nodo farò
> 
> tourism=hotel + amenity=restaurant ?


puoi fare due nodi se hanno al meno una proprietà diversa (capacity, name, 
ref:vatin, phone, addr, operator, stars, opening hours, smoking, ecc.), quindi 
praticamente sempre ;-)

Altrimenti vanno bene anche i due tags sullo stesso oggetto 


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

Re: [OSM-ja] 日本の「Acces / 交通手段による制限 - 陸上交通 車両種別アクセス」について

[yuu hayashi]

 # その他
このほかにも、vehicle,`motor_vehicle`,`motorcar`+`motorcycle`,`(motorcar AND (NOT
goods))`についての意見については

OSM wiki 「JA talk:Key:access / 1.9 その他、指摘、意見等」に記載しました。
https://wiki.openstreetmap.org/wiki/JA_talk:Key:access#.E3.81.9D.E3.81.AE.E4.BB.96.E3.80.81.E6.8C.87.E6.91.98.E3.80.81.E6.84.8F.E8.A6.8B.E7.AD.89
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] Correction des voies de chemin de fer gare d'Austerlitz

[Florian LAINEZ]

Salut François, j'aurai bien aimé mais je n'ai pas beaucoup de temps en ce
moment ...
J'ai récidivé en créant les voies 1 à 7 :
https://www.openstreetmap.org/changeset/63943374#map=17/48.83878/2.36916
bien que leur tracé soit bien fait le long des voies, je l'ai connecté de
manière arbitraire au réseau ferré  experts bienvenue.

Le ven. 26 oct. 2018 à 19:08, François Lacombe 
a écrit :

> Salut Florian,
>
> Tu m'accompagnes pour aller voir ca de visu ? :=)
>
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux 
>
>
> Le ven. 26 oct. 2018 à 18:57, Florian LAINEZ  a écrit :
>
>> Hello,
>> En faisant une mise-à-jour dans la gare Austerlitz j'ai remarqué qu'il
>> manquait des voies au niveau -1 le long des quais du RER C.
>> J'ai rajouté ça ici :
>> https://www.openstreetmap.org/way/638180762
>> https://www.openstreetmap.org/way/638180763
>> Je ne sais pas ce que ces voies deviennent au nord et au sud du quai ni
>> les détails à rajouter sur ces segments donc pour l'instant je les ai
>> raccordé au réseau ferré avec un fixme.
>> Peut-être que cela intéresse les spécialistes des réseaux, qui sait ? ;)
>>
>> Une fois sur la gare dans JOSM, utilisez les filtres de niveaux qui
>> apparaissent en haut à gauche pour bien visualiser ce que j'ai fait.
>>
>> PS : J'ai fait ça aussi dans la gare souterraine de Musée d'Orsay et je
>> vais continuer comme ça pour les autres gares parisiennes ...
>>
>> --
>>
>> *Florian Lainez*
>> @overflorian 
>> ___
>> 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
>


-- 

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

Re: [Talk-es] Propuesta de cambios en la normalización para España de carreteras nacionales

[yo paseopor]

On Sat, Oct 27, 2018 at 12:54 AM Jorge Sanz Sanfructuoso 
wrote:

>
> Yo no conozco esas revisiones que comentas en todas las carreteras menos
> en las nacionales.
>
-De las varias propuestas de normalización física de vías acabaron saliendo
cambios en varias autonomías, en la lista puedes ver comentarios sobre la
red de Canarias, Andalucía, Catalunya o Galicia entre otras. De todas
formas, dado que esta propuesta es objetiva (usa estadísticas como los IMD
de que disponen la mayoría de infraestructuras, sean de la administración
que sean, así como la velocidad media) o las características visibles de la
vía (cruces internivel, etc.) vale para cualquier administración y estaría
de acuerdo en aplicarla en cualquier carretera de cualquier administración.

>
> Hay un problema muy claro en esta propuesta y que todavía no esta aclarado
> y nunca aclaras y vas cogiendo de un sitio y de otro y no concretas. Tan
> pronto hablas de IMD, como de cruces a nivel, velocidad media, cómo algún
> otro parámetro. Una propuesta no puede ser una mezcla de todo sin definir
> cómo se usa claramente. No digo que no se pueda combinar todo, que puede
> que sí. Pero es que no concretas nada. Usa todo ¿cómo dice tu propuesta que
> se use todo eso concretamente? de una manera que no lleve a líos y
> ambigüedades? ¿Vamos por trocitos de carretera? ¿carreteras completas?
> Ya varias cosas de estas te las he comentado pero son cosas que si no se
> concretan claramente no se puede usar nada. Eso desde el primer mensaje que
> se ha dicho que no es objetivo es el mayor problema y todavía no lo he
> visto solucionado.
>

Desde el primer mensaje hablo de todos los aspectos de la propuesta. De
hecho siempre los ordeno de igual forma,porque ese es el orden de criterio
que según la propuesta se debe seguir. En caso de duda podemos usar el
criterio inferior .Y todo ello obtenido en una medida que sea proporcional:
Provincial.

Criterios

-Intensidad de uso: determinada por el IMD y por la coherencia de vías
adyacentes: para acceder a una vía de categoría inferior desde una autovía
se debe mantener mínimo la categoría de la vía  a la que se pretende
acceder (para evitar el autovía-tertiary-primary).
-En caso de existir dos salidas que compartan este acceso a otra vía, se
mantiene el tramo de la misma categoría a la que se accede.

A partir de ahí podemos tener otros parámetros en cuenta si estos primeros
no han sido suficientemente clarificadores:

-Experiencia de uso: determinada por la Velocidad Media (una velocidad
media alta da muchos números a pocos obstáculos, y altos límites de
velocidad, si hubiera dificultades el límite de velocidad bajaría)
-Características físicas de la vías, además en este orden, por seguridad:
cruces internivel, velocidad máxima, obstáculos en las vías (badenes,
tablas, etc.)

¿De todo ello , qué se necesita concretar más y qué sigue siendo subjetivo
o requiere mucha más información?

-¿Un número de IMD 10 veces más bajo que el de la vía de al lado es
subjetivo? De hecho si se ha detectado un error en el IMD en una estación
en concreto fue porque se vio que ese valor no era factible en esa zona.
-¿En plena Meseta y sin accidentes geográficos importantes una velocidad
media de 90 km/h vs. una velocidad media de 70 km/h es subjetiva?
-¿Es subjetivo el hecho de que en una vía de los 20 cruces que existen en
100 km un 90% sea internivel y que en otra vía en cambio sólo lo sea el
10%, con sus correspondientes límites de velocidad reducida para acometer
los cruces a nivel ?
-¿Es subjetivo que en esa misma vía además la velocidad máxima acostumbre a
estar entre los 100/80km/h o entre los 60/40 km/h ?
-¿Es subjetivo que esa misma vía no atraviese ninguna población o bien que
atraviese poblaciones y en su recorrido existan rotondas, badenes, tablas,
reductoras de velocidad, etc.?
-¿Es subjetivo que todo esto pueda estar redactado de forma exacta y clara
en la wiki (una vez aprobado, claro)?
-¿Es subjetivo que además la comunidad pueda ayudar al mapeador/a inexperto
que se decida a participar en la recategorización?

Recordemos que esta propuesta va para las vías de plataforma única (un
carril x sentido) dependientes de Fomento...porque si miramos el mapa estos
otros criterios ya se han tenido en cuenta para las vías de otras
administraciones (el ejemplo de Ávila-Salamanca vs. Leganés-Móstoles).
Especialmente esta propuesta afecta a aquellas vías que tienen en paralelo
una misma vía de categoría superior que antes de la clasificación no
existía y que absorbe la mayor parte del tráfico rodado, a veces
suplantando el recorrido e incluso partiendo el trazado de este haciendo
imposible su continuidad. Por las características de la propuesta dudo que
haya grandes cambios en los ejes sin alternativas de doble plataforma de
libertad de pago pues seguramente no habrá trasvase de vehículos entre
vías, su IMD ,aunque proporcional en su provincia, no bajará y por lo tanto
no variará de categoría.

>
> Vale los ruteadores entonces no 

[OSM-talk-fr] baignade interdite

[osm . sanspourriel]

Comme Paul parle d'une zone de baignade :

Le 27/10/2018 à 19:28, Paul Desgranges - desgranges.p...@laposte.net a 
écrit :
   -- les grandes superficies sont à regarder au cas par cas (par 
exemple https://www.openstreetmap.org/way/129407009

 est à transformer en "leisure=swimming_area")

ça me fait penser aux zones de baignade _interdite_.
Ça me semble plus particulièrement utile à indiquer sur le littoral: de 
superbes plages peuvent être de redoutables pièges.


Je n'avais pas trouvé de moyen de le décrire suivant le wiki. Vous avez 
des idées ?

https://wiki.openstreetmap.org/wiki/Swimming_and_bathing



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

Re: [Talk-es] Calles residenciales en Madrid

[yo paseopor]

Saludos
Creo recordad que el mensaje de Ikanian viene dado por algunos mensajes que
escribimos en Telegram sobre la nueva ordenanza de tráfico del Ayuntamiento
de Madrid, en el que se permite circular a las bicicletas por las vías
residenciales (señal S-28, plataforma única, etc.) en sentido contrario sin
ninguna otra indicación. Tal y como lo empecé a leer en la wiki pensé que
con la primera etiqueta sería suficiente. Pero si se sigue leyendo la wiki
se especifica que hace falta reforzarlo con el cycleway=opposite
" These roads should normally also be tagged with oneway
=yes and also oneway:bicycle
=no."
A raíz del mensaje de Daniel he mirado la otra definición y es cierto que
desde oneway:bycicle no se especifica  necesidad de otro etiquetaje.
Considero que estaría muy bien unificar situaciones desde las dos páginas
de la wiki y evidentmente actualizar sus traducciones

Salut i bicis en sentit contrari
yopaseopor


[1] https://wiki.openstreetmap.org/wiki/Key:cycleway


On Sat, Oct 27, 2018 at 12:52 PM dcapillae  wrote:

> Hola, Héctor.
>
> Ikanian ha preguntado cómo etiquetar calles residenciales de un solo
> sentido
> donde las bicis pueden circular en ambos sentidos. En ese caso, bastaría
> con
> añadir «oneway:bicycle=no» al etiquetado de la vía. No ha mencionado que
> haya carriles bici ni ninguna otra característica en particular. En
> general,
> con «oneway:bicycle=no» es suficiente para indicar que las bicis pueden
> circular a contramano por una vía de sentido único (oneway=yes), es decir,
> que puede circular en el sentido propio de la vía y en sentido contrario.
>
> Para conocer el etiquetado de casos particulares, habría que conocer los
> detalles para poder precisar.
>
>
>
> -
> 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-dk] Fodgængertunnel

[Uffe Kousgaard]

Ja, jeg skulle lige til at skrive det, men har ikke fundet på 
graphhoppers hjemmeside hvor tit det egentlig sker.


Jeg har også tilladt mig at trække tunnellen en anelse ud på hver side 
af vejen, så trapperne ikke forløber lige under hovedvejen.


Ellers så det rigtigt ud.

mvh
Uffe Kousgaard


On 28-10-2018 07:40, Michel Coene wrote:

Husk nu at graeshopper kun bliver opdateret en gang imellem.

Op zo 28 okt. 2018 00:44 schreef Troels Arvin >:


Hej,

Niels skrev bl.a.:
> Så forbind trapperne til İzmir Çanakkale Yolu

Det har jeg nu gjort (synes jeg):
https://www.openstreetmap.org/#map=19/39.54962/26.61866

Men alligevel ledes man som fodgænger fortsat ud på en stor omvej, så
måske har jeg alligevel ikke gjort det ordentlig?


https://www.openstreetmap.org/directions?engine=graphhopper_foot=39.55069%2C26.61871%3B39.54941%2C26.61845#map=17/39.54930/26.61377

-- 
Troels



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



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


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

Re: [Talk-dk] Fodgængertunnel

[Michel Coene]

Husk nu at graeshopper kun bliver opdateret en gang imellem.

Op zo 28 okt. 2018 00:44 schreef Troels Arvin :

> Hej,
>
> Niels skrev bl.a.:
> > Så forbind trapperne til İzmir Çanakkale Yolu
>
> Det har jeg nu gjort (synes jeg):
> https://www.openstreetmap.org/#map=19/39.54962/26.61866
>
> Men alligevel ledes man som fodgænger fortsat ud på en stor omvej, så
> måske har jeg alligevel ikke gjort det ordentlig?
>
>
> https://www.openstreetmap.org/directions?engine=graphhopper_foot=39.55069%2C26.61871%3B39.54941%2C26.61845#map=17/39.54930/26.61377
>
> --
> Troels
>
>
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk
>
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk