Re: [Talk-it] Galileo

2018-04-11 Thread Francesco Pelullo 
Il gio 12 apr 2018, 07:06 Andreas Lattmann 

>
> Submetrica??
> Non credo.


Non so se questi screenshot sono veri o no, ma mi piace pensare che lo
siano:


https://pbs.twimg.com/media/DVIiPGHWsAEo4DD.jpg

https://is1-ssl.mzstatic.com/image/thumb/Purple111/v4/41/57/a6/4157a6f7-142d-fb93-faa1-d2bf1d43a0bc/pr_source.png/300x0w.png

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

Re: [Talk-it] Galileo

2018-04-11 Thread Alfredo Gattai 
La precisione submetrica e' per ora solo fantasia. Il massimo ipotizzabile
con buon smartphone di fascia alta collegato ad antenna esterna si aggira
sui 3 metri ma e' ancora da verificare (affrontato argomento direttamente
con fornitore servizi galileo).

Al sumetrico si potra' pensare di arrivare quando saranno vere le seguenti
condizioni:

1) nuovi smartphone con all'interno il processore studiato ad Austin che
corregge il problema del multipath. Samsung si e' detta interessata a
miniaturizzarlo ma se ne parla da piu' di due anni.

2) accesso gratuito in tempo reale alle stazioni di correzzione
differenziale con hardware gia' aggiornato per Galileo.

Nel frattempo direi che smartphone (che vede galileo) + antenna esterna e'
puo' consentire qualche risultato migliore ma siamo sempre nell'ordine dei
metri

Alfredo

Il Gio 12 Apr 2018, 07:06 Andreas Lattmann  ha
scritto:

> >presi da app per smartphone che indicano una precisione stimata
> >submetrica
> >con Galileo attivato.
>
> Submetrica??
> Non credo. Solo dalle prossime versioni di smartphone hanno detto che
> arriveranno al submetrico. Almeno da quanto ho letto su Broadcom. Il mio
> smartphone si dovrebbe collegare a 6/8 (non ricordo di preciso)
> costellazioni contemporaneamente anche se all'atto pratico solo 4.
>
> 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] Galileo

2018-04-11 Thread Andreas Lattmann 
>presi da app per smartphone che indicano una precisione stimata
>submetrica
>con Galileo attivato.

Submetrica??
Non credo. Solo dalle prossime versioni di smartphone hanno detto che 
arriveranno al submetrico. Almeno da quanto ho letto su Broadcom. Il mio 
smartphone si dovrebbe collegare a 6/8 (non ricordo di preciso) costellazioni 
contemporaneamente anche se all'atto pratico solo 4.

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-in] Wikimedia maps - Internationalization

2018-04-11 Thread Shrinivasan T 
2018-04-12 7:11 GMT+05:30 Naveen Francis :
> Hi
>
> Beta version of multilingual Wikimedia maps
>
> Kannada:- https://maps-beta.wmflabs.org/?lang=kn#8/46.830/8.152
> Hindi :- https://maps-beta.wmflabs.org/?lang=hi#8/46.830/8.152
> Tamil:- https://maps-beta.wmflabs.org/?lang=ta#8/46.830/8.152
> Bengali :- https://maps-beta.wmflabs.org/?lang=bn#8/46.830/8.152
> Malayalam :- https://maps-beta.wmflabs.org/?lang=ml#8/46.830/8.152 [As usual
> has rendering issue]
>
> Thanks,
> naveenpf

Thanks for the efforts.

Cant see much tamil strings.

What we have to do to get tamil strings there?



-- 
Regards,
T.Shrinivasan


My Life with GNU/Linux : http://goinggnu.wordpress.com
Free E-Magazine on Free Open Source Software in Tamil : http://kaniyam.com

Get Free Tamil Ebooks for Android, iOS, Kindle, Computer :
http://FreeTamilEbooks.com

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

[Talk-in] Wikimedia maps - Internationalization

2018-04-11 Thread Naveen Francis 
Hi

Beta version of multilingual Wikimedia maps

Kannada:- https://maps-beta.wmflabs.org/?lang=kn#8/46.830/8.152
Hindi :- https://maps-beta.wmflabs.org/?lang=hi#8/46.830/8.152
Tamil:- https://maps-beta.wmflabs.org/?lang=ta#8/46.830/8.152
Bengali :- https://maps-beta.wmflabs.org/?lang=bn#8/46.830/8.152
Malayalam :- https://maps-beta.wmflabs.org/?lang=ml#8/46.830/8.152 [As
usual has rendering issue]

Thanks,
naveenpf
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [OSM-talk-fr] Import station essence (NavAds)

2018-04-11 Thread marc marc 
Histoire d'aider Stéphane,
voici le résumé des dernières nouvelles de la mailing imports
NB: la première partie n'est PAS mon avis, c'est ce que Ilya dit.
La maj de Ilya a été faite AVANT la publication des avis 
france/allemagne, c'est donc logique qu'il n'en a pas encore tenu compte.
En fin de message une proposition pour avancer :)

début du résumé mailing imports :

stats du jeux précédent : création de 1.5k et maj 4.7k en France

les tags modifiées sont uniquement "brand", "phone", "opening_hours" et 
"addr:postcode" "ref:navads"

le tag opening_hours n'est plus écrasé s'il est déjà présent dans osm.
uniquement ajouté si absent

vu qu'il a eu vent avant publication du rejet actuel des communautés 
française et allemande, il a divisé l'import en 5 http://audit.osmz.ru/

Les allemands ont aussi trouvées des problèmes de qualités :
- stations fantômes
- tag d'heure d'ouverture incorrecte
- contre l'ajout des addr:postcode
- problème de précision dans la localisation ~100m
- 15% d'erreur sur les données vérifiées

la dernière version proposée
https://lists.openstreetmap.org/pipermail/imports/2018-March/005475.html
les données
http://audit.osmz.ru/
l'avis de la communauté allemande
https://lists.openstreetmap.org/pipermail/imports/2018-April/005481.html

fin du résumé de la mailing imports, début de mon avis :)

on a beaucoup parlé qu'on avait une meilleur source d'info dispo pour la 
France mais quand on regarde l'état avec osmose, on a 3000 éléments en 
attente
http://osmose.openstreetmap.fr/fr/errors/?item=8200%2C8201%2C8202
Du coup, si on pense que cette source est de meilleur qualité, ne 
devrait-on pas l'utiliser activement pour faire :
- une édition de masse ou manuelle pour 314 maj
- essayer de qualifier les 606 intégrations proposées
- voir si les 2262 nouvelles stations proposées ont un sens (entre autre 
je me souviens que pour un bureau de poste, osmose ne tenait pas compte 
des objets effacés et proposait donc de les recréer.)
si ce processus abouti, on pourrait alors proposer un import de ces 
stations et voir ce qui reste dans l'import NavAds.
Peut être plus grand chose que NavAds ne propose que 1500 nouvelles 
stations contre 2262 via Osmose.
Evidement cela nécessite des bras constructifs :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-be] Ourthe = path?

2018-04-11 Thread Gerard Vanderveken 

Goedendag,

Hier heeft er eentje bij de rivier Ourthe 
 
een highway=path toegevoegd.

Is zo een dubbel gebruik van waterway en highway tags korrekt?

Met vriendelijke groeten,
Gerard
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-transit] Proposal for simplification of mapping public transport

2018-04-11 Thread Jo 
Mapping stop_position nodes is just fine. I would simply not add them to
the route relations.

Mapping platforms as ways or areas adds enhances detail. But no need to add
them to the route relations.

The proposal is about having 1 object to represent the stops for its whole
lifetime and nodes happen to be the most suitable kind of object for this.

Add all the pertinent details to this object and only add this object to
the route relations, once each time the vehicle serves it for that
particular itinerary variation. (route relation)

I've been using this scheme in Belgium, a country with 3-4 PT operators for
several years now and it works really well. I knew it was going to be hard
to propose a change, that for some is somewhat radical.

It does not mean that we're reverting back to PT "v1" though. Everything
can still be expressed in as much detail as needed or wanted. But to
enhance the detail during the lifetime of the stop, it won't be needed to
transfer tags from one object to another, or to replace objects in the
route relations.

We need a scheme that is easy to maintain by anybody and what I see
happening in Germany mostly, but also elsewhere around Europe, based on
what is described in the wiki is overly complex, thus making it only for
"experts", and we don't have enough of those.

Polyglot

2018-04-11 19:38 GMT+02:00 Roland Hieber :

> On Mon, Apr 09, 2018 at 07:19:32PM +0200, Jo wrote:
> > Here goes my proposal for a reform in mapping public transport:
> >
> > https://wiki.openstreetmap.org/wiki/Proposed_features/
> Public_Transport_map_all_stops_as_nodes
> [...]
>
> As I understand it, in Public Transport schema speech, this proposal
> comes down to removing all public_transport=stop_position nodes (i.e.
> the position where a train/bus/… stops on the street) from the route
> relations, and retaining the public_transport=platform information
> (i.e. where the passengers wait or where the station pole is located).
> This would be effectively reverting part of the Public Transport schema,
> and going back to the way platforms were mapped previously.
>
> However, a main reason why the Public Transport schema was adopted [1]
> was exactly this differentiation between stop position on the route and
> platform position/waiting area for the passengers.  This was done to
> increase the expressiveness of OpenStreeMap data, and to make
> information more easier obtainable for routing software.  After all, the
> two things are at different positions, and you cannot generally infer
> the one from the other.  Reverting to the old schema would therefore
> take away that expressiveness.
>
> [1]: https://wiki.openstreetmap.org/wiki/Proposed_features/
> Public_Transport#Goal_of_this_public_transport_proposal
>
> Furthermore, quoting from the proposal:
>
> > Rationale
> >
> > - nodes are convenient to work with and move, if needed, also using
> >   mobile apps
>
> This is true, but per the Public Transport schema you can already map
> both public_transport=stop_position and public_transport=platform as
> single nodes.  Your additional argument that both a node and a way could
> be added for the platform would not lead to more expressiveness, but
> only to more duplication of data.  (As simple as possible, as complex as
> necessary.)
>
> > - nodes have coordinates directly, no extra calculation required
> > - nodes are easy to work with using MapCSS, [...]
>
> See above.  Also, every way consists of nodes, which have a coordinates.
> Just take any.
>
> > - making comparison of location and tags with external sources is
> >   straightforward
>
> I don't know how this is meant, but the complexity of tag extraction
> from objects will be the same whether they are mapped on a node or
> mapped on a way.  Also the main work here is probably to match the
> external database schema to the OpenStreetMap data schema, as they will
> most probably not be very similar.
>
> That's all I can think of for now.
>
>  - Roland
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-it] Mancata attribuzione - Protezione Civile e Messaggero Veneto

2018-04-11 Thread Maurizio Napolitano 
2018-04-11 19:59 GMT+02:00 Cascafico Giovanni :
> Ne ero certo :-)
> Il Messaggero Veneto ha quindi usato una vostra immagine di gennaio senza
> chiedere?

Temo ancora che il problema sia come i giornali fanno gli screenshot :/

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

Re: [Talk-it] Mancata attribuzione - Protezione Civile e Messaggero Veneto

2018-04-11 Thread Cascafico Giovanni 
Ne ero certo :-)
Il Messaggero Veneto ha quindi usato una vostra immagine di gennaio senza
chiedere?

Il giorno 11 aprile 2018 19:14, Stefano Salvador  ha scritto:

> Ciao,
>
> La protezione civile FVG (dove lavoro) usa estesamente le mappe OSM
> cercando di avere cura di attribuirle correttamente.
>
> Non solo: mettiamo a disposizione i layer ortofoto e DTM che i mappatori
> usano da anni. Senza contare che almeno 4 colleghi sono mappatori attivi.
>
> Tutto ciò per dire che è stata solo una svista che sistemeremo al più
> presto.
>
> Stefano
>
> Il mer 11 apr 2018, 13:42 Cascafico Giovanni  ha
> scritto:
>
>> Il sito della Protezione Civile del Friuli Venezia Giulia pubblica una
>> mappa OSM senza attribuzione [1], con il proprio logo e quello dell'OGS
>> (Istuituto Nazionale Geofisica).
>> Essa inoltre viene riportata oggi nella versione cartacea (pag.3) del
>> quotidiano "Il Messaggero Veneto", a diffusione regionale, circa 50.000
>> copie.
>>
>>
>> [1] http://www.protezionecivile.fvg.it/it/la-protezione-
>> civile/eventi/terremoto-il-sistema-di-protezione-civile-
>> testa-le-schede-di
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-transit] Proposal for simplification of mapping public transport

2018-04-11 Thread Roland Hieber 
On Mon, Apr 09, 2018 at 07:19:32PM +0200, Jo wrote:
> Here goes my proposal for a reform in mapping public transport:
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_map_all_stops_as_nodes
[...]

As I understand it, in Public Transport schema speech, this proposal
comes down to removing all public_transport=stop_position nodes (i.e.
the position where a train/bus/… stops on the street) from the route
relations, and retaining the public_transport=platform information
(i.e. where the passengers wait or where the station pole is located).
This would be effectively reverting part of the Public Transport schema,
and going back to the way platforms were mapped previously.

However, a main reason why the Public Transport schema was adopted [1]
was exactly this differentiation between stop position on the route and
platform position/waiting area for the passengers.  This was done to
increase the expressiveness of OpenStreeMap data, and to make
information more easier obtainable for routing software.  After all, the
two things are at different positions, and you cannot generally infer
the one from the other.  Reverting to the old schema would therefore
take away that expressiveness.

[1]: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Goal_of_this_public_transport_proposal

Furthermore, quoting from the proposal:

> Rationale
>
> - nodes are convenient to work with and move, if needed, also using
>   mobile apps

This is true, but per the Public Transport schema you can already map
both public_transport=stop_position and public_transport=platform as
single nodes.  Your additional argument that both a node and a way could
be added for the platform would not lead to more expressiveness, but
only to more duplication of data.  (As simple as possible, as complex as
necessary.)

> - nodes have coordinates directly, no extra calculation required
> - nodes are easy to work with using MapCSS, [...]

See above.  Also, every way consists of nodes, which have a coordinates.
Just take any.

> - making comparison of location and tags with external sources is
>   straightforward

I don't know how this is meant, but the complexity of tag extraction
from objects will be the same whether they are mapped on a node or
mapped on a way.  Also the main work here is probably to match the
external database schema to the OpenStreetMap data schema, as they will
most probably not be very similar.

That's all I can think of for now.

 - Roland

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

Re: [Talk-it] Mancata attribuzione - Protezione Civile e Messaggero Veneto

2018-04-11 Thread Stefano Salvador 
Ciao,

La protezione civile FVG (dove lavoro) usa estesamente le mappe OSM
cercando di avere cura di attribuirle correttamente.

Non solo: mettiamo a disposizione i layer ortofoto e DTM che i mappatori
usano da anni. Senza contare che almeno 4 colleghi sono mappatori attivi.

Tutto ciò per dire che è stata solo una svista che sistemeremo al più
presto.

Stefano

Il mer 11 apr 2018, 13:42 Cascafico Giovanni  ha
scritto:

> Il sito della Protezione Civile del Friuli Venezia Giulia pubblica una
> mappa OSM senza attribuzione [1], con il proprio logo e quello dell'OGS
> (Istuituto Nazionale Geofisica).
> Essa inoltre viene riportata oggi nella versione cartacea (pag.3) del
> quotidiano "Il Messaggero Veneto", a diffusione regionale, circa 50.000
> copie.
>
>
> [1]
> http://www.protezionecivile.fvg.it/it/la-protezione-civile/eventi/terremoto-il-sistema-di-protezione-civile-testa-le-schede-di
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] BANO - raprochement fantoir cassé à grenoble, et peu de rues à grenoble

2018-04-11 Thread Philippe Verdy 
Je pense aussi qu'il y a un problème car même la page de suivi statistique
par commune produit une erreur quand on tente de la raffraichir, le
processus ne se termine pas non plus, les statistiques au final sont
partielles, ou ne prennent finalement pas en compte toutes les modifs en
base: les statistiques affichées sur la page de suivi par commune (et c'est
encore pire pour les statistiques par département: assez farfelues,
incompréhensibles, et au final une colonne "Indice 2020" ne correspond à
rien du tout et en tout cas pas du tout à ce que décrit la doc affichée sur
le gros bouton "?" d'aide dans le coin supérieur droit).
Selon mes propres comptages ces statistiques sont maintenant entièrement
fausses (et différentes aussi de ce qu'affiche le rendu BANO quand il
indique "n voies manquantes", apparemment ce n'est pas non plus le même
comptage, ou ce n'est pas synchronisé).
Difficile de faire un suivi des évolutions et motiver les gens à travailler
la BANO sur OSM et mesurer leur progrès (voir comment ils peuvent adapter
leurs façons de faire ou si celle-ci est adaptée, ou même de former de
petites équipes pour avec un calendrier raisonnable permettant de planifier
aussi d'autres activités dans OSM ou pour d'autres projets collaboratifs).

Un outil de suivi correcte serait pourtant nécessaire pour faire des
mapathons dans certaines zones (typiquement, une agglomération moyenne ou
une communauté de communes) où on veut compléter les adresses et parvenir à
un niveau de qualité suffisant pour ensuite développer des initiatives
locales, ou expérimenter une appli d'infos locales (voire même des
initiatives commerciales locales telles qu'une asso de commerçants locaux,
des assos sportives et culturelles désirant se positionner dans des
quartiers, ou des petits services à la personne par des indépendants
éventuellement groupés dans une asso, ou encore des initiatives de
riverains pas des assos de quartier)

Ce type d'appli visant à une excellente couverture des résidents locaux et
une assez bonne exhaustivité des adresses (mais au départ au moins toutes
les rues et tous les lieux-dits habités, puis enrichir la palette des
offres et POIs disponibles et toutes les opportunités locales de
développement des activités, même avec très peu d'argent mais beaucoup de
bonne volonté et d'entraide locale, et du partage qui ne dépendra pas d'un
gros fournisseur mondial demandant des abonnements et des infos privées et
des marges exhorbitantes sur les produits et services dérivées de ces
actions). Mais même si l'objectif est local d'abord, ensuite on peut
échanger les expériences locales et optimiser le processus, pour changer
d'échelle et passer un cap permettant d'aller plsu vite et généraliser pour
offrir une bonne couverture départementale, puis régionale ou nationale,
puis ensuite un suivi local des mises à jours avec de nouveaux outils de
contrôle qualité qu'il sera possible de développer quand on aura une vue
assez exhaustive du terrain pour établir des "règles", puis ensuite
déprécier d'anciennes pratiques (notamment sur le tagging lui-même ou
améliorer la liaison avec les outils de suivi, de rapprochement, ce qui
permettra aussi de détecter assez vite les pratiques abusives ou
destructives et mieux consolider les données avec moins de contributeurs
nécessaires qui se consacreront alors davantage à d'autres choses encore
plus intéressantes mais pour l'instant infaisable hors de toutes petites
expérimentations locales peu suivies car ne pouvant pas intéresser assez de
monde par son échelle limitée).


Le 11 avril 2018 à 18:45, Cactusbone  a écrit :

> Bonjour,
>
> sur https://cadastre.openstreetmap.fr/fantoir/ en chargeant Grenoble (code
> insee 38185), il y a une erreur dans la ressource chargée (malgré le retour
> http 200) qui indique notamment
>
> A problem occurred in a Python script.  Here is the sequence of
> function calls leading up to the error, in the order they occurred.
>
> bug ouvert par mon collègue ici :
> https://github.com/osm-fr/osm-vs-fantoir/issues/41
>
> sur http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#15/
> 45.1830/5.7222
> il est indiqué 8 voies d'écart
>
> mais sur http://bano.openstreetmap.fr/data/ le CSV pour le département 38
> fait 0 octet
> et je n'ai que 63 rues dans Grenoble dans le json, ce qui fait pas beaucoup
>
> Un souci de génération ?
>
>
>
> --
> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Grazie ai militari...

2018-04-11 Thread liste DOT girarsi AT posteo DOT eu 

Il 11/04/2018 15:58, Marco Bartalini ha scritto:
ragazzi ci sono novità sull'utilizzo di heatmap su id... sono ancora 
inutilizzabili a causa dello zoom...



/Marco Bartalini,



Uè! tüset và che ci sarebbero altri editor se non ti spiace, Josm, 
Potlach, Meerkartor, ecc. che abbisognerebbero di questo link aggiornato nè!




:) :) :)




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

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

Re: [OSM-talk-fr] wikidata vs brand:wikidata

2018-04-11 Thread PanierAvide 

Bonjour,

C'est bien ça, le wikidata=* doit pointer sur l'item correspondant à cet 
objet précis, donc là préférer brand:wikidata=* ou operator:wikidata=* 
(ou network:wikidata si Autolib' désigne le nom du réseau parisien).


Adrien.


Le 11/04/2018 à 16:13, Noémie Lehuby a écrit :


Bonjour,

Le tag wikidata correspondant à Autolib' a été ajouté sur les stations 
Autolib' de région parisienne.

Par exemple : https://www.openstreetmap.org/node/4472979080

Il me semble que cela devrait être dans un tag brand:wikidata (voire 
operator:wikidata). Je me trompe ?


Noémie



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



--
PanierAvide
Géomaticien & développeur

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

[OSM-talk-fr] BANO - raprochement fantoir cassé à grenoble, et peu de rues à grenoble

2018-04-11 Thread Cactusbone 
Bonjour,

sur https://cadastre.openstreetmap.fr/fantoir/ en chargeant Grenoble (code
insee 38185), il y a une erreur dans la ressource chargée (malgré le retour
http 200) qui indique notamment

A problem occurred in a Python script.  Here is the sequence of
function calls leading up to the error, in the order they occurred.

bug ouvert par mon collègue ici :
https://github.com/osm-fr/osm-vs-fantoir/issues/41

sur http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#15/45.1830/5.7222
il est indiqué 8 voies d'écart

mais sur http://bano.openstreetmap.fr/data/ le CSV pour le département 38
fait 0 octet
et je n'ai que 63 rues dans Grenoble dans le json, ce qui fait pas beaucoup

Un souci de génération ?



--
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-ca] DigitalGlobe building footprints for sale in Canada

2018-04-11 Thread James 
Digital Globe has been doing it for a while. They put machine learning on
their imagery and can extract buildings quite quickly and accurately

On Wed, Apr 11, 2018, 12:24 PM Bernie Connors, 
wrote:

>
> https://mailchi.mp/gogeomatics/canadian-building-footprints-now-available-off-the-shelf?e=b9f52af875
>
> I received this link by email today.  It looks like DigitalGlobe is trying
> to make some money from their building footprint data before it is
> available for free in OpenStreetmap.
>
> Bernie,
> --
> Bernie Connors
> New Maryland, NB
> ___
> 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-ca] DigitalGlobe building footprints for sale in Canada

2018-04-11 Thread Frederik Ramm 
Hi,

On 04/11/2018 06:22 PM, Bernie Connors wrote:
> I received this link by email today.  It looks like DigitalGlobe is
> trying to make some money from their building footprint data before it
> is available for free in OpenStreetmap.

In the PR footer it also has a nice explanation of why so many
businesses are so eager to apply Machine Learning to OSM:

"By applying artificial intelligence tools and machine learning
algorithms, imagery and data can yield critical insights about land use
and land change, vegetation, the built environment and much more.
Discover how location intelligence is transforming the way businesses
understand and derive insights from the built environment. Contact us
today."

OSM is the ideal test bed for a business wanting to hone their "machine
learning" skills - just dump your stuff into OSM and the community will
fix it, and you can then use these fixes as a new input for your machine
learning system...

... which will thereby of course fall fully under ODbL ;)

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] DigitalGlobe building footprints for sale in Canada

2018-04-11 Thread Bernie Connors 
https://mailchi.mp/gogeomatics/canadian-building-footprints-now-available-off-the-shelf?e=b9f52af875

I received this link by email today.  It looks like DigitalGlobe is trying
to make some money from their building footprint data before it is
available for free in OpenStreetmap.

Bernie,
-- 
Bernie Connors
New Maryland, NB
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-it] R: R: Aggiornare i confini

2018-04-11 Thread Martin Koppenhoefer 
2018-04-11 17:39 GMT+02:00 Fayor Uno :

> Preciso che esiste una porzione di mare, quella compresa tra la linea di
> costa e la linea di base, che è considerata "acque interne" e non "acque
> territoriali". Si tratta comunque di mare e non viene quindi ripartito tra
> gli enti territoriali, i cui confini si fermano alla linea di costa.
>



a quanto pare, la linea di costa ad oggi cammina verso l'interno, mentre
prima "cresceva" il territorio vicino alla foce (a causa del sedimento dal
fiume):
https://www.srf.ch/var/storage/images/_aliases/944w/auftritte/news/bilder/2017/10/11/node_14111671/153321106-2-ger-DE/bild.jpg

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

[Talk-it] R: R: Aggiornare i confini

2018-04-11 Thread Fayor Uno 
Preciso che esiste una porzione di mare, quella compresa tra la linea di costa 
e la linea di base, che è considerata "acque interne" e non "acque 
territoriali". Si tratta comunque di mare e non viene quindi ripartito tra gli 
enti territoriali, i cui confini si fermano alla linea di costa.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Mancata segnalazione

2018-04-11 Thread Jeawrong 
Devo dire che mi hanno dato retta, ora appare il corretto riferimento e link
che porta alla mappa. Bravi :)



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

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

[Talk-it] R: R: Aggiornare i confini

2018-04-11 Thread Fayor Uno 
On 11. Apr 2018, at 14:41, Vittorio Bertola  wrote:
In mare forse, ma sulla terra no: non esiste in Italia (a differenza ad esempio 
degli USA) il concetto di "territorio non incorporato"



Confermo, l'unica parte di "territorio" non ripartito tra enti territoriali 
minori è quello corrispondente alle acque territoriali.

La linea di costa è il "confine" dei comuni costieri e i suoi mutamenti 
comportano anche il mutamento di questo "confine".

Le acque interne (non solo laghi e fiumi ma anche alcuni porti e alcune 
lagune,credo sia il Ministero dell'Ambiente a stabilire l'andamento della linea 
di costa in questi casi particolari) fanno invece parte degli enti territoriali.

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

Re: [Talk-it] Mancata attribuzione - Protezione Civile e Messaggero Veneto

2018-04-11 Thread Martin Koppenhoefer 
penso che dovremmo riuscire senza grossi problemi di farli pubblicare un errata 
corrige nella prossima edizione, come anche nel caso del sole24ore, no? 
Dovrebbero scusarsi e dire che l’attribuzione dei dati era c Osm contributors, 
no?

Ci può dare una mano la WMI?

Ciao, Martin 

sent from a phone

> On 11. Apr 2018, at 13:37, Cascafico Giovanni  wrote:
> 
> Il sito della Protezione Civile del Friuli Venezia Giulia pubblica una mappa 
> OSM senza attribuzione [1], con il proprio logo e quello dell'OGS (Istuituto 
> Nazionale Geofisica). 
> Essa inoltre viene riportata oggi nella versione cartacea (pag.3) del 
> quotidiano "Il Messaggero Veneto", a diffusione regionale, circa 50.000 copie.
> 
> 
> [1] 
> http://www.protezionecivile.fvg.it/it/la-protezione-civile/eventi/terremoto-il-sistema-di-protezione-civile-testa-le-schede-di
> ___
> 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] R: Aggiornare i confini

2018-04-11 Thread Martin Koppenhoefer 


sent from a phone

> On 11. Apr 2018, at 14:41, Vittorio Bertola  wrote:
> 
> In mare forse, ma sulla terra no: non esiste in Italia (a differenza ad 
> esempio degli USA) il concetto di "territorio non incorporato".



se vale soltanto il catasto allora ci devono per forza essere porzioni di 
terreno che non fanno parte di un comune, perché le coste cambiano.

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

[OSM-talk-fr] wikidata vs brand:wikidata

2018-04-11 Thread Noémie Lehuby 
Bonjour, 

Le tag wikidata correspondant à Autolib' a été ajouté sur les stations
Autolib' de région parisienne.
Par exemple : https://www.openstreetmap.org/node/4472979080 

Il me semble que cela devrait être dans un tag brand:wikidata (voire
operator:wikidata). Je me trompe ? 

Noémie___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Grazie ai militari...

2018-04-11 Thread Marco Bartalini 
ragazzi ci sono novità sull'utilizzo di heatmap su id... sono ancora
inutilizzabili a causa dello zoom...




*Marco Bartalini,marcobartal...@gmail.com *

2018-04-05 14:59 GMT+02:00 Davide Sandona' :

> Trovato un'altro workaround per utilizzare la heatmap aggiornata:
> purtroppo è una procedura laboriosa, che richiede un account Strava La
> riporto comunque nel caso qualcuno avesse necessità di utilizzarla.
>
>1. Effettuare il login sulla heatmap di strava [1] (per non ripetere
>la procedura, ho selezionato l'opzione "ricorda l'accesso").
>2. Guardare i cookie riguardanti Strava (cercate la procedura per il
>vostro browser). A noi interessano i valori Key-Pair-Id, Policy, Signature
>(probabilmente noterete il prefisso CloudFront- prima del nome del cookie,
>ad esempio CloudFront- Key-Pair-Id).
>3. Copiamo i valori dei cookie su un file di testo e li concateniamo
>tra loro con il simbolo & (e commerciale). Ad esempio:
>Key-Pair-Id=VALORE1=VALORE2=VALORE3
>4. Apriamo JOSM, copiamo l'URL del layer Strava Cycling and Running.
>Dovrebbe essere questo: tms[3,11]:https://heatmap-external
>-{switch:a,b,c}.strava.com/tiles/both/bluered/{zoom}/{x}/{y}.png
>
>5. Lo modifichiamo in questo modo, andando ad appendere i valori dei
>cookie (notate il carattere ? aggiunto alla fine del precedente URL):
>tms[3,15]:https://heatmap-external-{switch:a,b,c}.strava
>.com/tiles-auth/both/bluered/{zoom}/{x}/{y}.png?Key-Pair-Id=
>VALORE1=VALORE2=VALORE3
>
> 
>
>
> Le modifiche all'URL sono le seguenti:
>
>- 11 -> 15: (zoom level)
>- /tiles/ -> /tiles-auth/: richiede l'autenticazione per utilizzare un
>valore di zoom più elevato.
>- /bluered/ -> /hot/ -> /gray/: qui possiamo cambiare il colore della
>heatmap. Generalmente la hot e la gray mostrano più dettagli.
>
> Spero vi possa essere utile.
>
> [1] www.strava.com/heatmap
>
> Davide.
>
> Il giorno 30 marzo 2018 17:46, Marco  ha scritto:
>
>> Il 30/03/2018 00:00, Davide Sandona' ha scritto:
>>
>> Si, funziona ma dal mio punto di vista va bene solo per allineare le
>>> immagini satellitari alla mappa, perché ad esempio i sentieri negli anni
>>> cambiano, quindi usando la vecchia heatmap si rischia di annullare il buon
>>> lavoro svolto da qualcun altro. I mappatori meno navigati potrebbero far
>>> più danni che altro.
>>> Io non credo di avere le conoscenze necessarie, però secondo me
>>> bisognerebbe risolvere il problema, non aggirarlo usando il vecchio (e
>>> quindi non aggiornato) layer.
>>>
>>
>> La tua preoccupazione è basata su una tua incomprensione della heatmap
>> stessa.
>>
>> Decisamente no.
>>
>> La heatmap di Strava viene creata con procedimento additivo di tutte le
>> tracce GPS nei loro database, tutte, dalle più vecchie alle più recenti.
>> Ciò significa che se una strada o sentiero fosse stato chiuso (o distrutto)
>> tu comunque lo vedrai nella heatmap qualora in passato sia stato percorso
>> dagli atleti che utilizzano Strava.
>> Io sono più preoccupato delle persone che utilizzano i dati (qualunque
>> dato) senza avere la minima idea della loro provenienza o del metodo di
>> raccolta.
>>
>> La vecchia heatmap mi sembra di aver capito che rappresenti la situazione
>> ante 2016 (potrei sbagliarmi sulla data), da quel momento non è più stata
>> aggiornata, mentre la "nuova" versione si aggiorna periodicamente con le
>> nuove tracce caricate dagli utenti.
>> Detto ciò, se un tratto di sentiero frana e viene creata una variante
>> sufficientemente distante dal sentiero originale, la nuova heatmap inizierà
>> piano piano a mostrare la variante ed il colore del tratto franato
>> diventerà piano piano sempre meno forte (perché non più percorso dagli
>> utenti), quella vecchia invece mostrerà solo il vecchio sentiero. Io sto
>> dicendo che questo continuo spingere per usare la vecchia heatmap
>> rischierebbe in casi come questo di portare i mappatori meno attenti alle
>> modifiche altrui, a cancellare il tratto di variante post frana, perché
>> sulla heatmap (vecchia) non risulta.
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Vinci Autoroutes et l'attribution à OpenStreetmap

2018-04-11 Thread Jean-Marc Liotier 
On Tue, 10 Apr 2018 15:18:17 +0200
Rpnpif  wrote:
> 
> Il manque la mention "et les contributeurs" mais bon

D'après
https://wiki.openstreetmap.org/wiki/Legal_FAQ#3a._I_would_like_to_use_OpenStreetMap_maps._How_should_I_credit_you.3F
cette mention est optionnelle:

"Because OpenStreetMap is its contributors, you may omit the word
'contributors' if space is limited"

Sur un écran de mobile, où chaque centimètre carré compte,
l'attribution "© Openstreetmap" fera donc parfaitement l'affaire, même
si la mention complète est recommandée dans d'autres contextes.

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

Re: [OSM-ja] 高速道路の定義について

2018-04-11 Thread Ras and Road 
Ras and Road です。

muramotoさん、的を外した回答で失礼しました。

「高規格幹線道路はどこ（信頼性の高いソース）に定義されているか」
高速道路（Ａ路線）は、「高速自動車国道の路線を指定する政令」です。
http://elaws.e-gov.go.jp/search/elawsSearch/elaws_search/lsg0500/detail?lawId=332CO000275
高速自動車国道に並行する一般国道自動車専用道路（Ａ’路線）と一般国道の自動車専用道路（Ｂ路線）は、正直なところ、理解していません。
国交省ホーム > 政策・仕事 > 審議会・委員会等 > 社会資本整備審議会 > 道路分科会 > 基本政策部会 >
第25回基本政策部会（平成20年10月10日） > 部会資料 > 資料４ 高規格幹線道路等の現在の手続き
http://www.mlit.go.jp/road/ir/kihon/25/4.pdf
の2ページに記載されているとおり、現在の手続きとしてＡ’路線は国交省道路局長が決定しますが、Ｂ路線は決定者の記載がありません。
適時性という観点で、個人のウェブサイトやWikipedia以外では、国交省の開通情報
http://www.mlit.go.jp/road/kaitsu/ や日本高速道路保有・債務返済機構のウェブサイトが有益かも知れません。
（どなたか、詳しい方はおられませんか？）

「現地検証の可能性」
道路のどこかを見て、それが高規格幹線道路か否かは判断できないと思います。道路の構造は地域高規格道路と区別できない場合が殆どでしょうし、特別なマーク等が記されているわけでもありません。
官報等で「高速自動車国道の路線を指定する政令の一部を改正する政令」「一般国道の指定区間を指定する政令の一部を改正する政令」に記載された起終点・経由地（いずれも地番表示）をブルーマップで住居表示に変換、乃至は法務局での公図確認を経て、道路位置を特定する手順が本来の手順だろうと想像します。（しかし、個人がやるにはコストと時間がかかりすぎます。）

肝心なところで「～と思います」「かも知れません」となってしまい、申し訳ないです。

** Ras and Road **
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [talk-au] Talk-au Digest, Vol 130, Issue 4

2018-04-11 Thread Andrew Harvey 
Hi Keith,

On 11 April 2018 at 20:53, K C  wrote:

> It seems to me that there are external links to a variety of websites in
> some of the WA OSM data. I draw your attention to the Department of Parks
> and Wildlife. That website too is copyright like every website in AU. I see
> no permissions sought as to whether the DPaW allows a map contributor to
> look at a photo on their website or glean some information as to whether
> there are toilets at a particular spot.
>

Oh external links aren't a problem. That's exactly what
http://wiki.openstreetmap.org/wiki/Key:website is for, OSM data consumers
can use that to point people to semi-official websites with more
information about objects in OSM.

You're right, the OpenStreetMap community respects the copyright of others
(and we are conservative so we don't try to push the limits of what we
think a court will uphold either) so we can't use copyrighted photos
without the right permissions to glean some information from.

That said it would be great people open up geotagged images to allow the
OSM community to use them as part of their mapping (like via Mapillary or
other platforms). Of course if they are your photos, you're free to use
information from them in OSM.


> Unfortunately I don't think they are going to upload their images to a
> site offshore either. You will find they use images from third parties with
> the appropriate permissions to display on their website. I display data
> from another large organisation that is funded by the WA Government. I
> asked permission to "link" to their particular pages via google maps and
> they replied with some html to insert into the balloon and said that was
> fine. My reason was that their information was very relevant to these
> remote beaches for people to be made aware of the danger at the particular
> beach in question.
>
> There is no breach of copyright if you look at a photo and then make an
> observation about the photo. There may be in other countries but not in AU.
> There is a breach of copyright if some one took that photo as their own and
> uploaded it to a photo sharing site etc. I choose to leave those images on
> my server and not anyone else's. Those "links" to the photo's are there for
> you the end user to see and understand what that 4wd surface actually is.
> Trust me you have people drawing ways in places that the unsuspecting
> commuter could end up in some serious shit.
>

It's pretty well accepted in OpenStreetMap that we take a whiter than white
approach to copyright and database copyright laws, meaning we don't glean
information from copyrighted photos and use that to update OSM, even if it
might be okay in one particular jurisdiction. This is evidenced by the fact
that you can't look at Google Street to gain information about data
uploaded to OSM.


> I will remove the instances of viewpoints/coastal vistas etc and stick to
> actually just detailing the actual track surfaces and other factors
> relating to the actual track.
>

If there are viewpoints there that you've surveyed personally or otherwise
know about from sources which we can use in OSM, please leave them in OSM
and I hope you choose to keep contributing that kind of information, it's
incredibly useful to those using OSM, myself included!
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-it] R: Aggiornare i confini

2018-04-11 Thread Vittorio Bertola 

Il 2018-04-10 17:09 Martin Koppenhoefer ha scritto:


2018-04-10 16:15 GMT+02:00 Fayor Uno :

Se il confine (parliamo dei confini comunali italiani) originariamente 
segue un corso d'acqua, o una strada, o un qualsiasi altro elemento 
naturale o artificiale, e successivamente questo riferimento sparisce 
o viene modificato nella realtà, la variazione non comporta il 
mutamento automatico del confine.


Confermo, anche perché nel momento in cui esiste un catasto di immobili 
e terreni ogni particella dello stesso è disegnata su una mappa e 
appartiene a un Comune, e non è legata (come era prima del catasto) a 
definizioni topologiche o a marcatori locali. Del resto attorno ai fiumi 
è normale vedere confini comunali che non corrispondono più al tracciato 
del fiume, col risultato di avere pezzi isolati di terreno su una sponda 
che appartengono al Comune sulla sponda opposta pur non essendo 
direttamente raggiungibili da esso.


le Regioni sono definiti attraverso i comuni, o ci sono confini a 
parte?


Non sono nemmeno sicuro che esista una legge che definisce 
esplicitamente i territori delle varie regioni, al di là dell'elenco 
scritto in Costituzione. Molte Regioni definiscono il proprio territorio 
nel proprio Statuto, e generalmente lo fanno scrivendo all'articolo 1 
che la Regione è costituita dai territori delle Province di ..., che a 
loro volta sono la somma dei Comuni. Quindi sì, le Regioni sono definite 
attraverso i Comuni.


Ci sono aree sul territorio italiano, che non fanno parte di alcun 
comune? (Sicuramente si, al meno alle coste, acque territoriali).


In mare forse, ma sulla terra no: non esiste in Italia (a differenza ad 
esempio degli USA) il concetto di "territorio non incorporato".

Ciao
--
vb.   Vittorio Bertola - vb [a] bertola.eu   <
>now blogging & more at http://bertola.eu/   <

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

Re: [Talk-hr] CC u OSM-u

2018-04-11 Thread Dražen Tutić 
Hvala. Da, u međuvremenu sam to shvatio i istovremeno izgubio volju za 
sudjelovanjem u OSM-u. Čini mi se da je stvar nepotrebno komplicirana i ovaj 
put na štetu OSM-a.

Na popisu dobivenih izricith dopustenja nema Hrvatske?! Što zaključiti?

Pozdrav, Dražen

 talk-hr-requ...@openstreetmap.org wrote 

Talk-hr posaljite mailing list poruke na
talk-hr@openstreetmap.org

Da biste se pretplatili ili odjavili preko Weba, posjetite
https://lists.openstreetmap.org/listinfo/talk-hr
ili, koristeci mail, posaljite poruku sa naslovom ili sadrzajem 'help'
na
talk-hr-requ...@openstreetmap.org

Osobi koja odrzava listu mozete se obratiti na
talk-hr-ow...@openstreetmap.org

Kada odgovarate, uredite Vasu Subject: liniju tako da je malo
detaljnja od "Re: Sadrzaj Talk-hr digesta..."


Današnje Teme:

   1. Re: CC licenca (Talk-hr Digest, Broj 93, Izdanje 8)
  (Darko Sokolić)


--

Message: 1
Date: Tue, 10 Apr 2018 20:30:17 +0200
From: Darko Sokolić 
To: talk-hr@openstreetmap.org
Subject: Re: [Talk-hr] CC licenca (Talk-hr Digest, Broj 93, Izdanje 8)
Message-ID: <7bf065a4-92ef-104f-fbdc-db3534416...@xnet.hr>
Content-Type: text/plain; charset=utf-8; format=flowed

Nažalost nije tako.

Dakle izvorni podaci
(http://data.gov.hr/dataset/registar-geografskih-imena) vele da su
licencirani pod Creative Commons Attribution,


Ja sam se ponadao da je bilo kakvog razvoja i približavanja OSMF i CC,
ali kad sam provjerio (što je eto malo potrajalo) ispalo je da se CC
pdoaci ne mogu samo preuzeti.

OSM podaci su pod licencom ODBl, ne CC (što se vidi na
https://wiki.openstreetmap.org/wiki/Creative_Commons).

U praksi ima i podataka pod CC licencom:
   https://www.openstreetmap.org/copyright
   https://wiki.openstreetmap.org/wiki/Contributors

No za CC podatke je potrebno tražiti izričitu dozvolu i dodatno
"/explicit waiver of the prohibition on applying Technological Effective
Measures/".
Tako barem vrlo konkretno piše ovdje:
https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/ .

Darko


On 14.03.2018 13:00, talk-hr-requ...@openstreetmap.org wrote:
> Subject:
> Re: [Talk-hr] Talk-hr Digest, Broj 93, Izdanje 7
> From:
> Dražen Tutić 
> Date:
> 13.03.2018 13:07
>
> To:
> "talk-hr@openstreetmap.org" 
>
>
> Podaci su objavljeni pod Creative Commons Attribution (CC-BY) dakle (uz 
> pretpostavku da su svi dionici svjesni da su podaci objavljeni pod tom 
> licencom i što ona znači) po meni nema prepreke za upotrebu na OSM uz 
> tagiranje izvornika podataka.
>
>
> Barem ja tako objašnjavam studentima i koristim u nastavi i objavljujem u 
> radovima.
>
>
> Na isti način sam postupio s podacima DZS-a o broju stanovnika po naseljima 
> koji su na portalu objavljeni pod istom tom licencom.
>
>
> Lijepi pozdrav,
>
> Dražen
>
>
> -
>
> Message: 1
> Date: Tue, 13 Mar 2018 12:50:58 +0100
> From: hbogner
> To:talk-hr@openstreetmap.org
> Subject: [Talk-hr] DGU registar geografskih imena na data.gov.hr
>  portalu
> Message-ID:
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> http://data.gov.hr/dataset/registar-geografskih-imena
>
> može li etko potvrditi da licenca odgovara i da to sad smijemo koristiti
> za OSM?
>
>
>



--

Subject: Podnožje Digesta

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


--

Kraj Talk-hr Digest, Broj 94, Izdanje 3
***
___
Talk-hr mailing list
Talk-hr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-hr

[Talk-it] Mancata attribuzione - Protezione Civile e Messaggero Veneto

2018-04-11 Thread Cascafico Giovanni 
Il sito della Protezione Civile del Friuli Venezia Giulia pubblica una
mappa OSM senza attribuzione [1], con il proprio logo e quello dell'OGS
(Istuituto Nazionale Geofisica).
Essa inoltre viene riportata oggi nella versione cartacea (pag.3) del
quotidiano "Il Messaggero Veneto", a diffusione regionale, circa 50.000
copie.


[1]
http://www.protezionecivile.fvg.it/it/la-protezione-civile/eventi/terremoto-il-sistema-di-protezione-civile-testa-le-schede-di
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] today's tragic helicopter accident in Bavaria

2018-04-11 Thread Oleksiy Muzalyev 
From my modest RPAS pilot experience, I can tell that during a flight 
planning, while using different sources: maps, satellite images, GPS 
traces, Wikimedia images, videos, etc. I kind of inadvertently build in 
my head a 3D model of an area, paying attention to distinctive 
landmarks, and especially to a point of landing.


In this particular case, I could map the control tower also only after I 
saw videos, aerial and ground photos, satellite images of the 
Haßfurt-Schweinfurt airport. After the tower, a major landmark, is on 
the map, here it is, I have got the 3D model.


Human brain works in 2D, that is why it takes years and years to train a 
good pilot. The professional term for a flight is: jump. Aircraft does 
not fly like a bird, it has got limitations of a jump (END - endurance, 
EET - estimated elapse time, ALT - alternate aerodrome, flight plan, 
etc.). A pilot error is not always caused by high spirits or illness, 
sometimes it is a result of objective limitations of human physiology. 
That is why any flight has got a flight planning phase.


By the way, if a smartphone battery has drained, if "Find My Phone" 
can’t locate the device, the last known location is displayed on a map.


Best regards,
Oleksiy

On 11.04.18 12:26, Martin Koppenhoefer wrote:


agreed, I would also believe that the military _also_ might look at 
OSM (every additional source is always useful), but very likely not 
for flying aircraft, still, I don't believe there is any correlation 
whatsoever between a military helicopter touching an airport control 
tower at daytime and good weather conditions, and this tower mapped in 
OSM or not. And even if it would have been a thunderstorm and foggy 
and night time, there wouldn't be any correlation between the accident 
and OSM (besides that you became aware of the tower and mapped it 
because of the news). Usually accidents like this happen because of 
high spirits or someone having an heart attack or similar.


On a sidenote, I think you overestimate the technology to find your 
smartphone, you would very likely not find it in the ocean or in a 
river or lake, or in a cave, or after some hours when the battery has 
drained, or in an area without cellphone or wireless reception, or if 
it was inside a shielding containment, etc. ;-)


Cheers,
Martin



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

Re: [talk-au] Talk-au Digest, Vol 130, Issue 4

2018-04-11 Thread K C 
It seems to me that there are external links to a variety of websites in
some of the WA OSM data. I draw your attention to the Department of Parks
and Wildlife. That website too is copyright like every website in AU. I see
no permissions sought as to whether the DPaW allows a map contributor to
look at a photo on their website or glean some information as to whether
there are toilets at a particular spot.

Unfortunately I don't think they are going to upload their images to a site
offshore either. You will find they use images from third parties with the
appropriate permissions to display on their website. I display data from
another large organisation that is funded by the WA Government. I asked
permission to "link" to their particular pages via google maps and they
replied with some html to insert into the balloon and said that was fine.
My reason was that their information was very relevant to these remote
beaches for people to be made aware of the danger at the particular beach
in question.

There is no breach of copyright if you look at a photo and then make an
observation about the photo. There may be in other countries but not in AU.
There is a breach of copyright if some one took that photo as their own and
uploaded it to a photo sharing site etc. I choose to leave those images on
my server and not anyone else's. Those "links" to the photo's are there for
you the end user to see and understand what that 4wd surface actually is.
Trust me you have people drawing ways in places that the unsuspecting
commuter could end up in some serious shit.

Opening the any link in a new tab or window involves using target="blank"
after the url. I am not going to insert that html into the web page or
image link due to the fact of this security issue.
https://www.jitbit.com/alexblog/256-targetblank---the-most-underestimated-vulnerability-ever/
This is something that could be done by others. At the moment it is the
safest way to view any external link and the OSM people will probably agree.

I will remove the instances of viewpoints/coastal vistas etc and stick to
actually just detailing the actual track surfaces and other factors
relating to the actual track.


Keith

On 10 April 2018 at 11:16, Andrew Harvey  wrote:

> Since you own the copyright in those photos, and unless you've licensed
> them such that information can be derived for use in OSM, then only you can
> use these photos to derive information for OSM.
>
> If you want to contribute these photos for anyone to use to derive
> information for OSM I suggest you upload them to Mapillary as then they'll
> automatically be available for OSM contributors, otherwise you'll need to
> explicitly say you allow this.
>
> The Contributors page is mainly for organisations who are contributing
> geodata for use in OSM where the licensing states we need to provide
> attribution.
>
> On 8 April 2018 at 23:42, K C  wrote:
>
>> I am the author of bushtrax.com and also added a lot of 4wd tracks
>> between 2008 and 2012 so should I add the listing to the contributors
>> index?. Interesting to note that the Holland Track trace came from
>> bushtrax.com as when I over laid my file it was a perfect match.
>>
>> Keith
>>
>> On 8 April 2018 at 18:50,  wrote:
>>
>>> Send Talk-au mailing list submissions to
>>> talk-au@openstreetmap.org
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> https://lists.openstreetmap.org/listinfo/talk-au
>>> or, via email, send a message with subject or body 'help' to
>>> talk-au-requ...@openstreetmap.org
>>>
>>> You can reach the person managing the list at
>>> talk-au-ow...@openstreetmap.org
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Talk-au digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>>1. tagged links to photos (nwastra)
>>>2. tagged links to photos (nwastra)
>>>3. Re: tagged links to photos (Andrew Harvey)
>>>4. Re: tagged links to photos (fors...@ozonline.com.au)
>>>5.  tagged links to photos (nwastra)
>>>6.  tagged links to photos (nwastra)
>>>7. Virtual Mapping Party for Brisbane (Joel H.)
>>>
>>>
>>> --
>>>
>>> Message: 1
>>> Date: Sun, 8 Apr 2018 12:31:29 +1000
>>> From: nwastra 
>>> To: OSM - Talk-au 
>>> Subject: [talk-au] tagged links to photos
>>> Message-ID: 
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>> Are we free to add tag links to images to OSM as in this.
>>> http://overpass-api.de/achavi/?changeset=57903447
>>> The https://www.bushtrax.com site is copyrighted so I assume that such
>>> links to the photos need to be either accompanied by permission or
>>> disclaimer or suitable licence or display of the copyright, etc from the
>>> copyright holder.

Re: [OSM-talk] today's tragic helicopter accident in Bavaria

2018-04-11 Thread Martin Koppenhoefer 
2018-04-11 12:08 GMT+02:00 Oleksiy Muzalyev :

> Martin,
>
> The OSM map is being used in a professional context on transportation. For
> example, very efficient Stockholm public transport system map:
> https://sl.se/en/ . I used this website myself while staying in
> Stockholm. I had to visit quite a few cities, but I never saw anything even
> remotely close by usefulness and efficiency to Stockholm public transport.
> Basically, one builds his/her life around this map over-there.
>
> As for the military, I saw a documentary about a modern military system,
> and there was on display of this system unmistakeably the OSM map.
>
> We tend to underestimate the technology available on our smartphones
> (including the OSM based maps). For example, I could find my lost
> smartphone even in another city in minutes, but some lost planes,
> helicopters, or RPAS are being searched for months or even years.



agreed, I would also believe that the military _also_ might look at OSM
(every additional source is always useful), but very likely not for flying
aircraft, still, I don't believe there is any correlation whatsoever
between a military helicopter touching an airport control tower at daytime
and good weather conditions, and this tower mapped in OSM or not. And even
if it would have been a thunderstorm and foggy and night time, there
wouldn't be any correlation between the accident and OSM (besides that you
became aware of the tower and mapped it because of the news). Usually
accidents like this happen because of high spirits or someone having an
heart attack or similar.

On a sidenote, I think you overestimate the technology to find your
smartphone, you would very likely not find it in the ocean or in a river or
lake, or in a cave, or after some hours when the battery has drained, or in
an area without cellphone or wireless reception, or if it was inside a
shielding containment, etc. ;-)

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

Re: [OSM-talk] today's tragic helicopter accident in Bavaria

2018-04-11 Thread Oleksiy Muzalyev 

Martin,

The OSM map is being used in a professional context on transportation. 
For example, very efficient Stockholm public transport system map: 
https://sl.se/en/ . I used this website myself while staying in 
Stockholm. I had to visit quite a few cities, but I never saw anything 
even remotely close by usefulness and efficiency to Stockholm public 
transport. Basically, one builds his/her life around this map over-there.


As for the military, I saw a documentary about a modern military system, 
and there was on display of this system unmistakeably the OSM map.


We tend to underestimate the technology available on our smartphones 
(including the OSM based maps). For example, I could find my lost 
smartphone even in another city in minutes, but some lost planes, 
helicopters, or RPAS are being searched for months or even years.


Best regards,
Oleksiy

On 11.04.18 10:04, Martin Koppenhoefer wrote:


sent from a phone


On 11. Apr 2018, at 09:31, Oleksiy Muzalyev  wrote:

I realize that the OSM map is not used by airmen, at least not officially.


even less as this was not a hobbyist but a military helicopter

Cheers,
Martin




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

Re: [Talk-it] Galileo

2018-04-11 Thread Francesco Pelullo 
Il mer 11 apr 2018, 11:46 Federico Cortese  ha
scritto:

>
> Forse mi sono espresso male, intendevo affidarsi ciecamente.


Si, certo.

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

Re: [Talk-it] Galileo

2018-04-11 Thread Federico Cortese 
2018-04-11 11:13 GMT+02:00 Francesco Pelullo :
>
>  Perché? :-)
>
> Federico, DEVI affidarti a quello che indica uno strumento.
> Casomai, non puoi confrontare quello che indicano DUE strumenti diversi.
>

Forse mi sono espresso male, intendevo affidarsi ciecamente.
Ovviamente non possiamo che seguire gli indici forniti dagli strumenti
per avere un riferimento sulla qualità delle misurazioni, ma la
certezza c'è solo quando abbiamo misure ridondanti o di controllo,
perchè quegli indici purtroppo potrebbero essere falsati.
Se leggo sul mio GPS che sto misurando con 50 cm di precisione, magari
invece la misura sarà sbagliata di 1 m, non potrò saperlo mai se non
ho altre misure di controllo, tutto qui.
Ma queste ovviamente sono cose che tu conosci bene, era solo un
discorso generico.

Ciao,
Federico

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

Re: [Talk-it] Galileo

2018-04-11 Thread Francesco Pelullo 
Il giorno 11 aprile 2018 10:53, Alessandro  ha scritto:

>
> OK, risposta breve: in ambito urbano senz'altro sì (da diversi metri a
> meno metri); in campo aperto non ho valutazioni spannometriche ma a
> sensazione direi un pò meglio
>

Perfetto.
Nel frattempo ho risolto, nel senso che ho trovato in rete degli screenshot
presi da app per smartphone che indicano una precisione stimata submetrica
con Galileo attivato.
Anche se si tratta di un valore fittizio, è sempre meglio dello stesso
valore fittizio raggiungibile con costellazioni GPS/GLONASS/Beidu.

Grazie a tutti

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

Re: [Talk-it] Galileo

2018-04-11 Thread Francesco Pelullo 
Il giorno 11 aprile 2018 10:31, Federico Cortese  ha
scritto:

>
> Verissimo! Non ci si può affidare a quello che indica uno strumento.
>


 Perché? :-)

Federico, DEVI affidarti a quello che indica uno strumento.
Casomai, non puoi confrontare quello che indicano DUE strumenti diversi.

Nel senso che non potrai mai confrontare il valore di HDOP e VDOP indicati
(con tutte le approssimazioni del caso) su uno smarphone e su un ricevitore
topografico.
Però puoi confrontare due smarphone o due ricevitori topografici.

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

Re: [Talk-ee] Rahvuspargid

2018-04-11 Thread Jaak Laineste 

Tõesti, ei tulnud selle peale et nii harva uuendatakse. Näib et 
https://a.tile.openstreetmap.org/8/143/76.png/status 
 annab staatuse et 
1.aprill uuendati ja tile lõpus /dirty võiks ju taasgenereerimise algatada, 
mille ka tegin.

Vihje sain googlest :) 
https://help.openstreetmap.org/questions/1049/how-to-trigger-a-repaint-for-a-specific-osm-map-tile
 


Kui nüüd renderdaja queue numbreid uurida (ei tea kas on õige masin ikka): 
https://munin.openstreetmap.org/openstreetmap/render.openstreetmap/index.html#renderd
 
,
 siis dirty queue on enamus päevast oma piiri 4K peal, ja renderdatakse kuni 30 
metatile/sekundis, seega ~133 sekundit peaks queue aeg olema , kui näppudel 
õigesti arvutan. Aga võibolla see sõltub ka veel zoomist, sest mõne minuti 
pärast näidatakse /status clean, aga renderduse kuupäev on ikka 1.aprill. Või 
siis /dirty ei tööta üldse reaalselt. Tuleb kannatlik olla lihtsalt nii suurte 
asjadega.


Jaak

> On 11 Apr 2018, at 11:00, Mihkel Oviir  wrote:
> 
> Ee, ilmselt mitte. Võtab lihtsalt aega, kuni ka väiksemad suurendused äta 
> tailitakse. Olen ka tähele pannud, et näiteks teede muutmisel toimub cache 
> uuendamine kiiremini kui maakatte muutmisel. Ju neil mingi keerulisem 
> prioriteetide süsteem seal on.
> 
> 11. aprill 2018 10:48 kirjutas Margus Värton  >:
> Kas seda ümberrenderdamist kuidagi sisse suumides jõuga käivitada ei saa?
> 
> - M - 
> 
> K, 11. aprill 2018 10:43 Mihkel Oviir  > kirjutas:
> Mulle tundub, et teise kujundusega väiksematel suurendustel toimubki cache 
> uuendamine oluliselt harvem, nädal viivitust on täiesti tavaline.
> 
> terv,
> Mihkel
> 
> 11. aprill 2018 09:46 kirjutas Jaak Laineste  >:
> Hoi,
> 
> oskab keegi minust targem öelda, miks lisatud Vilsandi ja Matsalu RP piire 
> näidatakse suurema suurendusega (13 ja enam), aga väiksematega mitte? Samas 
> Lahemaa näiteks on ka väiksematel suurendustel (8+) olemas . Ega cache ei ole 
> seal nii pikk, lisatud said juba nädal tagasi? Midagi tag-itud valesti?
> 
> Jaak
> 
>> On 4 Apr 2018, at 13:43, Jaak Laineste > > wrote:
>> 
>> 
>> Selle topoloogilise puhtusega on nagu ta on - vaeva on üksjagu et seda 
>> saada, villa kogus on mõneti küsitav. 
>> 
>> Tegin siis kaks näidist: Matsalu https://www.openstreetmap.org/way/576248440 
>>  ja Vilsandi RP 
>> https://www.openstreetmap.org/relation/8178686 
>> 
>> 
>> Kaks asja jäid veel silma:
>> 
>>  1) Varasemad rahvuspargid - Lahemaa, Soomaa näivad olevat 
>> boundary=national_park + leisure=nature_reserve, mitte 
>> boundary=protected_area. Tundub et muidu ei renderdatagi, ja arutelu sellel 
>> teemal pole valmis 
>> https://github.com/gravitystorm/openstreetmap-carto/issues/603 
>> , kuigi 
>> suund nagu oleks ikka protected_area poole, sest iga kaitseala 
>> “national_park” nimetamine on liiga USAlik lähenemine.  
>> 
>>  2) Õigused. Andmed WFS metainfo kohaselt on CC-BY 4.0, ja selle kohta on 
>> selge juhis https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/ 
>>  et tuleb 
>> eraldi luba küsida, see ei ole automaatselt kasutatav. Keda 
>> keskkonnaagentuuris kiusata sellega?
>> 
>> 
>> 
>> —
>> Jaak
>> 
>> 
>> 
>>> On 4 Apr 2018, at 12:56, Mihkel Oviir >> > wrote:
>>> 
>>> :D mul just oli sama mõte, et võtaks teema uuesti üles. Just kammisin 
>>> EELISe lehte, et kust ma need andmed kunagi leidsin.
>>> 
>>> 1) Märgenduse ettepanek on ok. Andmete päritolu tuleks ka lisada.
>>> 2) Piirjoonte ühtlustamise osas. Mina ei tea, on sel mõtet? Mis see reaalne 
>>> kasu on, et ei võiks lihtsalt importida nii nagu on? Ja edasi siis kui 
>>> keegi kuskil rannajoont õgvendab, siis juba viib soovi korral ise kokku. 
>>> Mina ei näpiks. Sama on ju ka haldusjaotusega, tihti järgib mingeid kraave 
>>> jne. Et mis siis õige on, kas jookseb mööda telge või tegelikult on piir 
>>> kraavi servas? Aga minu arvamus ainult.
>>> 3) Olemasolevad lk alad. Paar tükki on vahepeal juurde tulnud, Soomaa ja 
>>> Loodi. Seal peaks vaatama, kas olemasolev on üldse valiidne, kui ei ole, 
>>> siis asendama.
>>> 
>>> terv,
>>> Mihkel
>>> 
>>> 4. aprill 2018 12:42 kirjutas Jaak Laineste >> >:
>>> 
>>> Võtaks veel korra seda kaitsealade teemat ülesse. 
>>> 
>>> Mis on olemas?
>>> 
>>> Kokku ma leian EELIS-est

Re: [Talk-it] Galileo

2018-04-11 Thread Alessandro 

Il 11/04/2018 10:27, Francesco Pelullo ha scritto:




Intendevo solo chiederti se, rispetto ad una precisione media indicata 
abitualmente da qualsiasi smartphone (3m-4m), con Galileo ci fossero dei 
miglioramenti (ad esempio 1m o meno).




OK, risposta breve: in ambito urbano senz'altro sì (da diversi metri a 
meno metri); in campo aperto non ho valutazioni spannometriche ma a 
sensazione direi un pò meglio


Alessandro

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

Re: [Talk-it] Galileo

2018-04-11 Thread Federico Cortese 
2018-04-11 10:04 GMT+02:00 Alessandro Palmas :
> Non è un segreto ma non ho potuto comparare la precisione con alcun
> riferimento.
> Per fare questo occorre andare in un campo prove topografico, non basta
> certo affidarsi a quello che ti dice uno strumento.
> Anche le indicazioni di un Garmin C62 riguardo la precisione sono quello che
> lo strumento pensa riesca a raggiungere stimando la "sfera d'incertezza"
> (perdonate il termine non tecnico).
>

Verissimo! Non ci si può affidare a quello che indica uno strumento.
Anche se un campo prove topografico è forse eccessivo per quel tipo di
dispositivi, diciamo che per avere un'idea basterebbe un semplice
confronto con misure eseguite con GPS professionali, tipo quelli che
uso per i rilievi topografici.
Peccato che siamo lontani :)

Ciao,
Federico

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

Re: [Talk-it] Galileo

2018-04-11 Thread Francesco Pelullo 
Il giorno 11 aprile 2018 10:04, Alessandro Palmas <
alessandro.pal...@wikimedia.it> ha scritto:

>
>
> Non è un segreto ma non ho potuto comparare la precisione con alcun
> riferimento.
>


Alessandro certe volte sei esageratamente pignolo. :-)
Conosco perfettamente cos'è un campo prova topografico e non intendevo
chiederti quale fosse il valore assoluto raggiunto.
Intendevo solo chiederti se, rispetto ad una precisione media indicata
abitualmente da qualsiasi smartphone (3m-4m), con Galileo ci fossero dei
miglioramenti (ad esempio 1m o meno).
Se poi questo valore fosse esatto o meno, non importa ai fini pratici.
Tutto qui.

Grazie comunque.

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

Re: [Talk-it] Routing ciclismo con VAM

2018-04-11 Thread Francesco Pelullo 
Il giorno 10 aprile 2018 17:10, Andreas Lattmann 
ha scritto:

> Brouter?
> A memoria mi sembra che fa ciò che cerchi anche se bisogna smanettare
> sulla configurazione...



Grazie per la segnalazione, non lo conoscevo.
In effetti è proprio come scrivevi tu, è possibile definire un profilo di
routing personalizzato.
Grazie di nuovo.

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

Re: [Talk-it] Galileo

2018-04-11 Thread Alessandro Palmas 

Il 11/04/2018 08:59, Francesco Pelullo ha scritto:



... e se non è un segreto, mi diresti anche qual è la precisione massima 
raggiunta con 28 satelliti?





Non è un segreto ma non ho potuto comparare la precisione con alcun 
riferimento.
Per fare questo occorre andare in un campo prove topografico, non basta 
certo affidarsi a quello che ti dice uno strumento.
Anche le indicazioni di un Garmin C62 riguardo la precisione sono quello 
che lo strumento pensa riesca a raggiungere stimando la "sfera 
d'incertezza" (perdonate il termine non tecnico).



Questo è quello che abbiamo a Genova, quando avrò il tempo di farci un 
salto in una bella giornata ti saprò dire


http://www.dicca.unige.it/geomatica/campoprova/index.php/2013-10-11-12-35-43/campo

Qui un video con Domenico, Bianca e Tiziano, girato dal buon Riccardo 
"Colsub"


https://www.youtube.com/watch?v=yZWHB4LlOa4

Il sito è qui http://overpass-turbo.eu/s/xN3

Alessandro Ale_Zena_IT

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

Re: [OSM-talk] today's tragic helicopter accident in Bavaria

2018-04-11 Thread Martin Koppenhoefer 


sent from a phone

> On 11. Apr 2018, at 09:31, Oleksiy Muzalyev  
> wrote:
> 
> I realize that the OSM map is not used by airmen, at least not officially.


even less as this was not a hobbyist but a military helicopter 

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

Re: [Talk-ee] Rahvuspargid

2018-04-11 Thread Margus Värton 
Kas seda ümberrenderdamist kuidagi sisse suumides jõuga käivitada ei saa?

- M -

K, 11. aprill 2018 10:43 Mihkel Oviir  kirjutas:

> Mulle tundub, et teise kujundusega väiksematel suurendustel toimubki cache
> uuendamine oluliselt harvem, nädal viivitust on täiesti tavaline.
>
> terv,
> Mihkel
>
> 11. aprill 2018 09:46 kirjutas Jaak Laineste :
>
>> Hoi,
>>
>> oskab keegi minust targem öelda, miks lisatud Vilsandi ja Matsalu RP
>> piire näidatakse suurema suurendusega (13 ja enam), aga väiksematega mitte?
>> Samas Lahemaa näiteks on ka väiksematel suurendustel (8+) olemas . Ega
>> cache ei ole seal nii pikk, lisatud said juba nädal tagasi? Midagi tag-itud
>> valesti?
>>
>> Jaak
>>
>> On 4 Apr 2018, at 13:43, Jaak Laineste  wrote:
>>
>>
>> Selle topoloogilise puhtusega on nagu ta on - vaeva on üksjagu et seda
>> saada, villa kogus on mõneti küsitav.
>>
>> Tegin siis kaks näidist: Matsalu
>> https://www.openstreetmap.org/way/576248440 ja Vilsandi RP
>> https://www.openstreetmap.org/relation/8178686
>> 
>>
>> Kaks asja jäid veel silma:
>>
>>  1) Varasemad rahvuspargid - Lahemaa, Soomaa näivad olevat
>> *boundary=national_park* +* leisure=nature_reserve*, mitte *boundary=*
>> *protected_area*. Tundub et muidu ei renderdatagi, ja arutelu sellel
>> teemal pole valmis
>> https://github.com/gravitystorm/openstreetmap-carto/issues/603, kuigi
>> suund nagu oleks ikka protected_area poole, sest iga kaitseala
>> “national_park” nimetamine on liiga USAlik lähenemine.
>>
>>  2) *Õigused*. Andmed WFS metainfo kohaselt on CC-BY 4.0, ja selle kohta
>> on selge juhis
>> https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/ et tuleb
>> eraldi luba küsida, see ei ole automaatselt kasutatav. Keda
>> keskkonnaagentuuris kiusata sellega?
>>
>>
>>
>> —
>> Jaak
>>
>>
>>
>> On 4 Apr 2018, at 12:56, Mihkel Oviir  wrote:
>>
>> :D mul just oli sama mõte, et võtaks teema uuesti üles. Just kammisin
>> EELISe lehte, et kust ma need andmed kunagi leidsin.
>>
>> 1) Märgenduse ettepanek on ok. Andmete päritolu tuleks ka lisada.
>> 2) Piirjoonte ühtlustamise osas. Mina ei tea, on sel mõtet? Mis see
>> reaalne kasu on, et ei võiks lihtsalt importida nii nagu on? Ja edasi siis
>> kui keegi kuskil rannajoont õgvendab, siis juba viib soovi korral ise
>> kokku. Mina ei näpiks. Sama on ju ka haldusjaotusega, tihti järgib mingeid
>> kraave jne. Et mis siis õige on, kas jookseb mööda telge või tegelikult on
>> piir kraavi servas? Aga minu arvamus ainult.
>> 3) Olemasolevad lk alad. Paar tükki on vahepeal juurde tulnud, Soomaa ja
>> Loodi. Seal peaks vaatama, kas olemasolev on üldse valiidne, kui ei ole,
>> siis asendama.
>>
>> terv,
>> Mihkel
>>
>> 4. aprill 2018 12:42 kirjutas Jaak Laineste :
>>
>>>
>>> Võtaks veel korra seda kaitsealade teemat ülesse.
>>>
>>> Mis on olemas?
>>>
>>> Kokku ma leian EELIS-est ("WFS:
>>> https://gsavalik.envir.ee/geoserver/eelis/ows?version=2.0.0&;,
>>> kr_kaitseala tabel) ligi 900 polügoni, suuremad on 5 rahvusparki, 166 LKA-d
>>> ja 150 MKA-d [1]. Lisaks suur hulk väiksemaid pargikesi jne.
>>>
>>> Küsimused, mis tekkisid:
>>>
>>> 1) kuidas neid *märgendada*? Ma kasutaksin
>>> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area
>>> tag-e, sinna Wiki lehe tabelisse tuleks lisada Eesti spetsiifika. Minu
>>> ettepanekud:
>>>   -  klassid (protect_class) võiksid olla RP=2, LKA=4, MKA=5.
>>>   - Kaasa võiks EELIS-est võtta kr_kood tunnuse (tag: eelis:kr_kood,
>>> näiteks KLO1000300 Matsalu puhul)
>>>   - Tüüp läheb  protection_title alla : "rahvuspark", "looduskaitseala"
>>> ja "maastikukaitseala", vastavalt.
>>>
>>> 2) kuidas *piirjooni* ühtlustada? See on juba põnevam probleem, sest
>>> Eestis on üksjagu rannajoont ja kaitsealad järgivad sageli ka muid
>>> looduslikke objekte nagu jõed/järved, mis on eri andmetes erinevas kohas.
>>> Näiteks proovisin Vilsandi RP-d , mis on suhteliselt lihtne, sest piir on
>>> suuresti meres. Ikkagi on seal mõned kilomeetrid rannajoont kokku vedada,
>>> vt [2]  Seal hall joon on EELIS-e RP piir, värviline on OSM andmed, ja taga
>>> on metsanduse orto JOSM-is.
>>>  - Minu ettepanek: kasutada alati vana piirjoont OSM-is, ehk siis
>>> eeldatavasti adminpiiridest pärit üsna täpset rannajoont, ja tekitada uued
>>> polügonid/relatsioonid nende põhjal. Jooksvalt võib ju orto taustale võtta
>>> ja rannajoont täpsustada enda aeropildi lugemise oskuse kohaselt. Kes
>>> oskab, viib sujuvalt sisse ka Amsterdami nulli parandi :)
>>>
>>> Paar vaadet:
>>> [1] kaitselad üldse
>>> https://www.dropbox.com/s/u0ylv9wgrjrldlh/Screenshot%202018-04-04%2012.11.50.png?dl=0
>>> [2] rannajoon Vilsandi RP-l
>>> https://www.dropbox.com/s/z1wvi9iu8pmh12k/Screenshot%202018-04-04%2011.50.26.png?dl=0
>>>
>>>
>>>
>>> On 11 Jan 2017, at 01:46, Teet Koitjärv 
>>> wrote:
>>>
>>> Tere.
>>>
>>> Kõikide kaitsealade andmed on

Re: [OSM-talk] today's tragic helicopter accident in Bavaria

2018-04-11 Thread Oleksiy Muzalyev 
I worked for ten years as a GOO (ground operations) at a major airline. 
I realize that the OSM map is not used by airmen, at least not officially.


I am a certified RPAS (remotely piloted aircraft system) pilot. While 
planning a flight at a certain place I look at the official special maps 
(for example RPAS restrictions map for CH [1]). But, since no map is 
perfect, I look also at the OSM map, different satellite imagery, Google 
map, Wikimedia ground and aerial images of a place, if existing, Youtube 
videos, etc. to understand what is expecting me at this place.


It is even more complicated for helicopter pilots, since risk and 
responsibility are incomparably higher. It is not impossible that an 
airman has got a smartphone in his pocket with map apps, and during long 
autopilot flight has a look at a place where he has to land, which is 
the most complex part of a flight.


Unfortunately, helicopter wire and obstacle strikes happen quite often, 
and the stats are nearly evenly split between day and nighttime events. 
86% of the fatal accidents occur in clear weather with good visibility [2].


My point is that it would at least not harm if towers, not only control 
towers, but communication, observation towers, and other tall structures 
are present on a map with an icon. It would be useful for everyone, 
since these landmarks are visible from far away at day and night.


[1] 
https://map.geo.admin.ch/?topic=aviation=de=ch.swisstopo.pixelkarte-grau=ch.bazl.einschraenkungen-drohnen_opacity=0.6=1379,2863=2635778.01=1187912.46=2
[2] 
http://aviationweek.com/business-aviation/how-avoid-helicopter-wire-strikes


With best regards,
Oleksiy

On 11.04.18 03:21, Jack Armstrong dan...@sprynet.com wrote:

Are you saying you think an aviation accident could have been avoided if OSM 
data was better? I've been an air traffic controller for 38 years. Aviation 
hazards, such as towers at airports, are well charted on navigational charts 
and airport diagrams which pilots are required to use. A pilot would never use 
OSM as a means of avoiding ground hazards at an airport. Besides, this 
particular accident happened at 10:00 A.M. local time, meaning it was daylight. 
The vast majority of aviation accidents are the result of pilot error. If a 
helicopter pilot allows his rotor blades to collide with a clearly visible 
object, that is negligence on the captain's part.



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

[Talk-it] Milano: mappare l'accessibilità del Fuorisalone

2018-04-11 Thread Alessandro Palmas 

Ciao,
in occasione del Fuorisalone della Milano Design week 
https://fuorisalone.it/2018/ stiamo partendo con la mappatura 
dell'accessibilità della zona Tortona.


E' un progetto per ora in fase di test che coinvolge Aiasmilano e una 
startup qui a BASE. Dopo questo primo test faremo il punto della 
situazione e replicheremo nei prossimi mesi durante gli altri eventi a 
Milano.


Vorremmo indicare i percorsi accessibili e info sui locali (aggiornati 
da alcuni studenti del POLIMI che effettueranno verifiche aggiornando i 
dati di Aiasmilano rilevati prima dell'Expo) nell'area delimitata da 
San'Agostino, Porta Genova e Viale Troya.
Ho iniziato a mappare i marciapiedi e a fare Mapillary sugli stessi. Chi 
passa in zona se può dia una mappata o una mapillarata :-)


Alessandro Ale_Zena_IT

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

Re: [Talk-it] Galileo

2018-04-11 Thread Francesco Pelullo 
Il giorno 11 aprile 2018 08:55, Alessandro Palmas <
alessandro.pal...@wikimedia.it> ha scritto:

>
> Certo che funziona. A volta ne aggancio 4, una volta sono arrivato a ben 7.
>
> Non si può dire "migliora di X", ma il fatto di poter agganciare più
> satelliti, soprattutto in gole naturali o urban canyon, senz'altro aiuta.
> A novembre in Calabria con l'S8 ho agganciato 28 satelliti.
>
>
... e se non è un segreto, mi diresti anche qual è la precisione massima
raggiunta con 28 satelliti?

:-)

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

Re: [Talk-it] Galileo

2018-04-11 Thread Alessandro Palmas 

Il 11/04/2018 00:01, Francesco Pelullo ha scritto:

Ciao a tutti

Qualcuno utilizza un ricevitore abilitato per il sistema di 
posizionamento Galileo?

Funziona?




Certo che funziona. A volta ne aggancio 4, una volta sono arrivato a ben 7.

Non si può dire "migliora di X", ma il fatto di poter agganciare più 
satelliti, soprattutto in gole naturali o urban canyon, senz'altro aiuta.

A novembre in Calabria con l'S8 ho agganciato 28 satelliti.

Alessandro Ale_Zena_IT

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

Re: [Talk-it] Convergere su Recanati per 118

2018-04-11 Thread Alessandro Palmas 

Buongiorno,
da richiesta di Riccardo ho creato un nuovo task per i comuni di 
Montelupone, Potenza Picena, Montefano


http://osmit-tm.wmflabs.org/project/32

Alessandro Ale_Zena_IT

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

Re: [OSM-talk] today's tragic helicopter accident in Bavaria

2018-04-11 Thread Jack Armstrong dan...@sprynet.com 
Yes, I understand. I'm just explaining the situation in greater detail in case there is a misunderstanding :)-Original Message-
From: Jo 
Sent: Apr 11, 2018 10:27 AM
To: Milo van der Linden 
Cc: "Jack Armstrong dan...@sprynet.com" , "Jack Armstrong dan...@sprynet.com" , Oleksiy Muzalyev , Talk Openstreetmap 
Subject: Re: [OSM-talk] today's tragic helicopter accident in Bavaria

derbies -> debrisOleksiy's attention was drawn to that airport because of the tragic fatality. He noticed the tower was not mapped, so he mapped it.Cheers,Jo2018-04-11 8:17 GMT+02:00 Milo van der Linden :Dear Armstrong, please be aware that Oleksiy is no native english speaker. In his culture and language that is probably not what he is saying.

Kind regards,

Milo van der LindenOn April 11, 2018 3:21:17 AM GMT+02:00, "Jack Armstrong dan...@sprynet.com"  wrote:
Are you saying you think an aviation accident could have been avoided if OSM data was better? I've been an air traffic controller for 38 years. Aviation hazards, such as towers at airports, are well charted on navigational charts and airport diagrams which pilots are required to use. A pilot would never use OSM as a means of avoiding ground hazards at an airport. Besides, this particular accident happened at 10:00 A.M. local time, meaning it was daylight. The vast majority of aviation accidents are the result of pilot error. If a helicopter pilot allows his rotor blades to collide with a clearly visible object, that is negligence on the captain's part.-Original Message-From: Oleksiy Muzalyev Sent: Apr 10, 2018 3:44 PMTo: Talk Openstreetmap Subject: [OSM-talk] today's tragic helicopter accident in BavariaGood evening,There was an helicopter accident at the airport Flugplatz Haßfurt-Schweinfurt. One man from the ground staff was killed by derbies when helicopter's propeller blades touched the control tower.On the news video [1] and on the aerial image of the airport [2] it is clearly visible that the tower building is not in the same row with other buildings, it is a bit outstanding.This tower was not mapped neither on the Google maps, nor on the OSM. I mapped it by now on the OSM: https://www.openstreetmap.org/#map=18/50.01720/10.52705 with the tag: tower:type=aircraft_control, which has got a nice map icon.In general, towers, not only aircraft_control, but also communication, and others, are well visible even from far away, and could serve as good landmarks. That is why it makes sense to map towers.[1] https://rtlnext.rtl.de/cms/bundeswehr-hubschrauber-rammt-tower-flughafenmitarbeiter-von-truemmern-erschlagen-4148088.html[2] https://de.wikipedia.org/wiki/Flugplatz_Ha%C3%9Ffurt-Schweinfurt#/media/File:Flugplatz_Ha%C3%9Ffurt_Schweinfurt.jpgWith best regards,Oleksiytalk mailing listtalk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talktalk mailing listtalk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk
-- 
Verstuurd vanaf mijn mobiel. Fouten voorbehouden.___
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-ee] Rahvuspargid

2018-04-11 Thread Jaak Laineste 
Hoi,

oskab keegi minust targem öelda, miks lisatud Vilsandi ja Matsalu RP piire 
näidatakse suurema suurendusega (13 ja enam), aga väiksematega mitte? Samas 
Lahemaa näiteks on ka väiksematel suurendustel (8+) olemas . Ega cache ei ole 
seal nii pikk, lisatud said juba nädal tagasi? Midagi tag-itud valesti?

Jaak

> On 4 Apr 2018, at 13:43, Jaak Laineste  wrote:
> 
> 
> Selle topoloogilise puhtusega on nagu ta on - vaeva on üksjagu et seda saada, 
> villa kogus on mõneti küsitav. 
> 
> Tegin siis kaks näidist: Matsalu https://www.openstreetmap.org/way/576248440 
>  ja Vilsandi RP 
> https://www.openstreetmap.org/relation/8178686 
> 
> 
> Kaks asja jäid veel silma:
> 
>  1) Varasemad rahvuspargid - Lahemaa, Soomaa näivad olevat 
> boundary=national_park + leisure=nature_reserve, mitte 
> boundary=protected_area. Tundub et muidu ei renderdatagi, ja arutelu sellel 
> teemal pole valmis 
> https://github.com/gravitystorm/openstreetmap-carto/issues/603 
> , kuigi suund 
> nagu oleks ikka protected_area poole, sest iga kaitseala “national_park” 
> nimetamine on liiga USAlik lähenemine.  
> 
>  2) Õigused. Andmed WFS metainfo kohaselt on CC-BY 4.0, ja selle kohta on 
> selge juhis https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/ 
>  et tuleb 
> eraldi luba küsida, see ei ole automaatselt kasutatav. Keda 
> keskkonnaagentuuris kiusata sellega?
> 
> 
> 
> —
> Jaak
> 
> 
> 
>> On 4 Apr 2018, at 12:56, Mihkel Oviir > > wrote:
>> 
>> :D mul just oli sama mõte, et võtaks teema uuesti üles. Just kammisin EELISe 
>> lehte, et kust ma need andmed kunagi leidsin.
>> 
>> 1) Märgenduse ettepanek on ok. Andmete päritolu tuleks ka lisada.
>> 2) Piirjoonte ühtlustamise osas. Mina ei tea, on sel mõtet? Mis see reaalne 
>> kasu on, et ei võiks lihtsalt importida nii nagu on? Ja edasi siis kui keegi 
>> kuskil rannajoont õgvendab, siis juba viib soovi korral ise kokku. Mina ei 
>> näpiks. Sama on ju ka haldusjaotusega, tihti järgib mingeid kraave jne. Et 
>> mis siis õige on, kas jookseb mööda telge või tegelikult on piir kraavi 
>> servas? Aga minu arvamus ainult.
>> 3) Olemasolevad lk alad. Paar tükki on vahepeal juurde tulnud, Soomaa ja 
>> Loodi. Seal peaks vaatama, kas olemasolev on üldse valiidne, kui ei ole, 
>> siis asendama.
>> 
>> terv,
>> Mihkel
>> 
>> 4. aprill 2018 12:42 kirjutas Jaak Laineste > >:
>> 
>> Võtaks veel korra seda kaitsealade teemat ülesse. 
>> 
>> Mis on olemas?
>> 
>> Kokku ma leian EELIS-est 
>> ("WFS:https://gsavalik.envir.ee/geoserver/eelis/ows?version=2.0.0; 
>> ", 
>> kr_kaitseala tabel) ligi 900 polügoni, suuremad on 5 rahvusparki, 166 LKA-d 
>> ja 150 MKA-d [1]. Lisaks suur hulk väiksemaid pargikesi jne. 
>> 
>> Küsimused, mis tekkisid:
>> 
>> 1) kuidas neid märgendada? Ma kasutaksin 
>> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area 
>>  tag-e, 
>> sinna Wiki lehe tabelisse tuleks lisada Eesti spetsiifika. Minu ettepanekud:
>>   -  klassid (protect_class) võiksid olla RP=2, LKA=4, MKA=5. 
>>   - Kaasa võiks EELIS-est võtta kr_kood tunnuse (tag: eelis:kr_kood, näiteks 
>> KLO1000300 Matsalu puhul) 
>>   - Tüüp läheb  protection_title alla : "rahvuspark", "looduskaitseala" ja 
>> "maastikukaitseala", vastavalt. 
>> 
>> 2) kuidas piirjooni ühtlustada? See on juba põnevam probleem, sest Eestis on 
>> üksjagu  rannajoont ja kaitsealad järgivad sageli ka muid looduslikke 
>> objekte nagu jõed/järved, mis on eri andmetes erinevas kohas. Näiteks 
>> proovisin Vilsandi RP-d , mis on suhteliselt lihtne, sest piir on suuresti 
>> meres. Ikkagi on seal mõned kilomeetrid rannajoont kokku vedada, vt [2]  
>> Seal hall joon on EELIS-e RP piir, värviline on OSM andmed, ja taga on 
>> metsanduse orto JOSM-is. 
>>  - Minu ettepanek: kasutada alati vana piirjoont OSM-is, ehk siis 
>> eeldatavasti adminpiiridest pärit üsna täpset rannajoont, ja tekitada uued 
>> polügonid/relatsioonid nende põhjal. Jooksvalt võib ju orto taustale võtta 
>> ja rannajoont täpsustada enda aeropildi lugemise oskuse kohaselt. Kes oskab, 
>> viib sujuvalt sisse ka Amsterdami nulli parandi :)
>> 
>> Paar vaadet:
>> [1] kaitselad üldse 
>> https://www.dropbox.com/s/u0ylv9wgrjrldlh/Screenshot%202018-04-04%2012.11.50.png?dl=0
>>  
>> 
>> [2] rannajoon Vilsandi RP-l 
>> https://www.dropbox.com/s/z1wvi9iu8pmh12k/Screenshot%202018-04-04%2011.50.26.png?dl=0
>>  
>> 
>>   
>> 
>>

Re: [OSM-talk] today's tragic helicopter accident in Bavaria

2018-04-11 Thread Oleksiy Muzalyev 

Thank you, Jo. It was a typing error. It is definitively debris.

With best regards,
Oleksiy

On 11.04.18 08:27, Jo wrote:

derbies -> debris

Oleksiy's attention was drawn to that airport because of the tragic 
fatality. He noticed the tower was not mapped, so he mapped it.


Cheers,

Jo

2018-04-11 8:17 GMT+02:00 Milo van der Linden >:


Dear Armstrong, please be aware that Oleksiy is no native english
speaker. In his culture and language that is probably not what he
is saying.

Kind regards,

Milo van der Linden

On April 11, 2018 3:21:17 AM GMT+02:00, "Jack Armstrong
dan...@sprynet.com "
> wrote:

Are you saying you think an aviation accident could have been
avoided if OSM data was better? I've been an air traffic
controller for 38 years. Aviation hazards, such as towers at
airports, are well charted on navigational charts and airport
diagrams which pilots are required to use. A pilot would never
use OSM as a means of avoiding ground hazards at an airport.
Besides, this particular accident happened at 10:00 A.M. local
time, meaning it was daylight. The vast majority of aviation
accidents are the result of pilot error. If a helicopter pilot
allows his rotor blades to collide with a clearly visible
object, that is negligence on the captain's part.
-Original Message-

From: Oleksiy Muzalyev > Sent: Apr 10, 2018
3:44 PM To: Talk Openstreetmap > Subject: [OSM-talk]
today's tragic helicopter accident in Bavaria Good
evening, There was an helicopter accident at the airport
Flugplatz Haßfurt-Schweinfurt. One man from the ground
staff was killed by derbies when helicopter's propeller
blades touched the control tower. On the news video [1]
and on the aerial image of the airport [2] it is clearly
visible that the tower building is not in the same row
with other buildings, it is a bit outstanding. This tower
was not mapped neither on the Google maps, nor on the OSM.
I mapped it by now on the OSM:
https://www.openstreetmap.org/#map=18/50.01720/10.52705

with the tag: tower:type=aircraft_control, which has got a
nice map icon. In general, towers, not only
aircraft_control, but also communication, and others, are
well visible even from far away, and could serve as good
landmarks. That is why it makes sense to map towers. [1]

https://rtlnext.rtl.de/cms/bundeswehr-hubschrauber-rammt-tower-flughafenmitarbeiter-von-truemmern-erschlagen-4148088.html


[2]

https://de.wikipedia.org/wiki/Flugplatz_Ha%C3%9Ffurt-Schweinfurt#/media/File:Flugplatz_Ha%C3%9Ffurt_Schweinfurt.jpg


With best regards, Oleksiy


talk mailing list talk@openstreetmap.org

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



talk mailing list talk@openstreetmap.org

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



-- 
Verstuurd vanaf mijn mobiel. Fouten voorbehouden.


___
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: [OSM-talk] today's tragic helicopter accident in Bavaria

2018-04-11 Thread Jo 
derbies -> debris

Oleksiy's attention was drawn to that airport because of the tragic
fatality. He noticed the tower was not mapped, so he mapped it.

Cheers,

Jo

2018-04-11 8:17 GMT+02:00 Milo van der Linden :

> Dear Armstrong, please be aware that Oleksiy is no native english speaker.
> In his culture and language that is probably not what he is saying.
>
> Kind regards,
>
> Milo van der Linden
>
> On April 11, 2018 3:21:17 AM GMT+02:00, "Jack Armstrong dan...@sprynet.com"
>  wrote:
>
>> Are you saying you think an aviation accident could have been avoided if OSM 
>> data was better? I've been an air traffic controller for 38 years. Aviation 
>> hazards, such as towers at airports, are well charted on navigational charts 
>> and airport diagrams which pilots are required to use. A pilot would never 
>> use OSM as a means of avoiding ground hazards at an airport. Besides, this 
>> particular accident happened at 10:00 A.M. local time, meaning it was 
>> daylight. The vast majority of aviation accidents are the result of pilot 
>> error. If a helicopter pilot allows his rotor blades to collide with a 
>> clearly visible object, that is negligence on the captain's part.
>>
>>
>> -Original Message-
>>
>>> From: Oleksiy Muzalyev 
>>> Sent: Apr 10, 2018 3:44 PM
>>> To: Talk Openstreetmap 
>>> Subject: [OSM-talk] today's tragic helicopter accident in Bavaria
>>>
>>> Good evening,
>>>
>>> There was an helicopter accident at the airport Flugplatz
>>> Haßfurt-Schweinfurt. One man from the ground staff was killed by derbies
>>> when helicopter's propeller blades touched the control tower.
>>>
>>> On the news video [1] and on the aerial image of the airport [2] it is
>>> clearly visible that the tower building is not in the same row with
>>> other buildings, it is a bit outstanding.
>>>
>>> This tower was not mapped neither on the Google maps, nor on the OSM. I
>>> mapped it by now on the OSM:
>>> https://www.openstreetmap.org/#map=18/50.01720/10.52705 with the tag:
>>> tower:type=aircraft_control, which has got a nice map icon.
>>>
>>> In general, towers, not only aircraft_control, but also communication,
>>> and others, are well visible even from far away, and could serve as good
>>> landmarks. That is why it makes sense to map towers.
>>>
>>> [1]
>>> https://rtlnext.rtl.de/cms/bundeswehr-hubschrauber-rammt-tower-flughafenmitarbeiter-von-truemmern-erschlagen-4148088.html
>>>
>>> [2]
>>> https://de.wikipedia.org/wiki/Flugplatz_Ha%C3%9Ffurt-Schweinfurt#/media/File:Flugplatz_Ha%C3%9Ffurt_Schweinfurt.jpg
>>>
>>> With best regards,
>>>
>>> Oleksiy
>>>
>>>
>>>
>>> --
>>>
>>> talk mailing list
>>> talk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk
>>>
>>
>> --
>>
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>>
> --
> Verstuurd vanaf mijn mobiel. Fouten voorbehouden.
>
> ___
> 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: [OSM-talk] today's tragic helicopter accident in Bavaria

2018-04-11 Thread Milo van der Linden 
Dear Armstrong, please be aware that Oleksiy is no native english speaker. In 
his culture and language that is probably not what he is saying.

Kind regards,

Milo van der Linden

On April 11, 2018 3:21:17 AM GMT+02:00, "Jack Armstrong dan...@sprynet.com" 
 wrote:
>Are you saying you think an aviation accident could have been avoided
>if OSM data was better? I've been an air traffic controller for 38
>years. Aviation hazards, such as towers at airports, are well charted
>on navigational charts and airport diagrams which pilots are required
>to use. A pilot would never use OSM as a means of avoiding ground
>hazards at an airport. Besides, this particular accident happened at
>10:00 A.M. local time, meaning it was daylight. The vast majority of
>aviation accidents are the result of pilot error. If a helicopter pilot
>allows his rotor blades to collide with a clearly visible object, that
>is negligence on the captain's part.
>
>
>-Original Message-
>>From: Oleksiy Muzalyev 
>>Sent: Apr 10, 2018 3:44 PM
>>To: Talk Openstreetmap 
>>Subject: [OSM-talk] today's tragic helicopter accident in Bavaria
>>
>>Good evening,
>>
>>There was an helicopter accident at the airport Flugplatz 
>>Haßfurt-Schweinfurt. One man from the ground staff was killed by
>derbies 
>>when helicopter's propeller blades touched the control tower.
>>
>>On the news video [1] and on the aerial image of the airport [2] it is
>
>>clearly visible that the tower building is not in the same row with 
>>other buildings, it is a bit outstanding.
>>
>>This tower was not mapped neither on the Google maps, nor on the OSM.
>I 
>>mapped it by now on the OSM: 
>>https://www.openstreetmap.org/#map=18/50.01720/10.52705 with the tag: 
>>tower:type=aircraft_control, which has got a nice map icon.
>>
>>In general, towers, not only aircraft_control, but also communication,
>
>>and others, are well visible even from far away, and could serve as
>good 
>>landmarks. That is why it makes sense to map towers.
>>
>>[1] 
>>https://rtlnext.rtl.de/cms/bundeswehr-hubschrauber-rammt-tower-flughafenmitarbeiter-von-truemmern-erschlagen-4148088.html
>>
>>[2] 
>>https://de.wikipedia.org/wiki/Flugplatz_Ha%C3%9Ffurt-Schweinfurt#/media/File:Flugplatz_Ha%C3%9Ffurt_Schweinfurt.jpg
>>
>>With best regards,
>>
>>Oleksiy
>>
>>
>>
>>___
>>talk mailing list
>>talk@openstreetmap.org
>>https://lists.openstreetmap.org/listinfo/talk
>
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk

-- 
Verstuurd vanaf mijn mobiel. Fouten voorbehouden.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk