Re: [OSM-talk] no_feature_tag_nodes

[Maarten Deen]

On 2018-04-13 05:02, Jack Armstrong dan...@sprynet.com wrote:

OSM Inspector tags some individual address nodes as errors. For
example, these nodes located inside the lateral boundaries of
buildings:

https://www.openstreetmap.org/edit?node=5438712543#map=19/39.68899/-104.86454

I guess I'm reading it wrong, but I can't seem to locate anything
specifically on the wiki that refers to this. Is there some
documentation I can refer to which addresses this specific situation?


Maybe it's complaining about the description tag without having some 
other tag to indicate what this node is?


Maarten

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

[OSM-talk] no_feature_tag_nodes

[Jack Armstrong dan...@sprynet.com]

OSM Inspector tags some individual address nodes as errors. For example, these nodes located inside the lateral boundaries of buildings:https://www.openstreetmap.org/edit?node=5438712543#map=19/39.68899/-104.86454I guess I'm reading it wrong, but I can't seem to locate anything specifically on the wiki that refers to this. Is there some documentation I can refer to which addresses this specific situation?Thanks

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

[Talk-TW] Pokemon Go玩家問題

[Dennis Raylin Chen]

Hi All

最近因PTT Pokemon Go板討論打超夢問題，擁進不少人加公園

但有些不滿用relation繪製的公園無法出超夢，惱羞成怒而開始塗鴨行為，可以看 OSMCha

連結

台灣這邊需要多多巡視，以及與因Pokemon Go而加入繪圖的人多多溝通

Dennis
___
Talk-TW mailing list
Talk-TW@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-tw

[Talk-us] Strange edits in area I'm working on

[David Wisbey]

In the last couple of days some very strange new edits have been occurringright 
in the area I have been working on.
https://www.openstreetmap.org/edit?editor=potlatch2#map=19/39.69619/-104.90209
39.69619, -104.90209
Greentree Village Apartments, Denver, CO
1.  A couple of days ago these untagged nodes started showing up, in this part 
of Denver at least.To see them of course you would have to start editing as 
they don't get rendered.  Checking the Historyof a few, I found that they were 
created on the 8th of April by user Victoria1901, a new mapper sinceMarch 13, 
2018.  I sent the user a message asking about this and saying that this is not 
a proper way ofmapping; apparently they were "adding parking".  But many of 
these nodes' locations don't even makesense, some being on primary arterials 
such as South Parker Road, which have NO parking.  I have deletedmany of these 
nodes, but most are still there.  
2.  Today I discovered that another user, nakamuraa, also a new mapper since 
April 03, 2018, added serviceroads in Greentree Village apartment complex while 
I slept, nearly on top of service roads that I added lastnight.  Of course I 
sent nakamuraa a message and hope to get a reply soon.  Surely even if the new 
roads Iadded last night were not yet rendered, at least the mapper would have 
seen them when they were editing,so why would they map practically on top of 
what was already there?  
*** I have thought for a few years that it needs to be maybe not quite so easy 
to become an OSM mapper.  An onlinecourse, requiring a passing grade, should be 
a minimum.  Also, they should probably be assigned an experiencedmapper as a 
temporary mentor who would help them get going and check their work for a 
while. ***

3.  I have also noticed in some locations that duplicate buildings exist.  For 
example, today I saw perhaps 2 dozenor so buildings (mapped as building=yes 
with no other tags but should have been building=terrace) in a townhouse 
development in Alexandria, Virginia, near the intersection of Michigan Avenue 
and Bernard Street, just south of Slaters Lane.  I have seen this kind of thing 
before in other places.  I am assuming that these buildings are from an import 
that was mistakenly done twice.  In Potlatch white circles appear over the 
nodes in the ways that have the same exact coordinates, so they're easy to spot 
and delete.

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

[Diversity-talk] Diverse conferences need you!

[Rebecca Firth]

Hi

The HOT and FOSS4G community have been working hard to develop the
conference Code of Conduct for the upcoming event in Tanzania (
http://2018.foss4g.org/). The goal is to ensure the conference is as
welcoming and safe as it can be, and maintain a commitment to diverse and
inclusive conferences. Part of this means hosting conferences in countries
where HOT works as an organisation and where there are strong local OSM
communities. However, this does raise important concerns about safety and
security for attendees. We hope a re-drafted CoC will help all future
events happening in countries with similar local laws to Tanzania, to
ensure they can protect the interests and security of attendees as best as
possible. SOTM Africa, future, SOTMs, etc etc..

The Summit/FOSS4G Working Groups have a re-drafted policy and would love
feedback from an as-diverse-as-possible group. If you're keen to support,
please get in touch with Amelia and Rachel in copy, who will send you a
copy of the policy and gladly hear your feedback.

Thanks,

Rebecca

-- 
*Rebecca Firth*
Community and Partnerships Manager
rebecca.fi...@hotosm.org 
@RebeccaFirthy

*Humanitarian OpenStreetMap Team*
*Using OpenStreetMap for Humanitarian Response & Economic Development*

You can #mapthedifference today! Donate.hotosm.org

web  | twitter  | facebook
 | donate 
___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [Talk-it] Su taginfo, è possibile sapere le date creazione dei tag?

[Martin Koppenhoefer]

sent from a phone

> On 10. Apr 2018, at 18:17, liste DOT girarsi AT posteo DOT eu 
>  wrote:
> 
> Quanto in oggetto per una mia curiosità per capire quando è stato creato un 
> tag la prima volta, ho guardato le API [0], ma non mi pare lo permettono, ed 
> anche la wiki di OSM [1], ma non capisco se si può, da quel che vedo no, 
> confermate?


sarebbe un progettino, si potrebbe leggere il full history planet oggetto per 
oggetto e scrivere ogni tag con la data della versione in una tabella, se un 
tag già c’è e la data è più nuova nella tabella, si sovrascrive.
La tabella diventerà molto grande...

Conosci http://taghistory.raifer.tech/
? Non dà una data precisa (credo) però è molto utile perché si vede l’andamento.

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

Re: [Talk-us] Amtrak network=Amtrak tagging

[OSM Volunteer stevea]

Neither this talk-us list nor I have received any response to my request for 
comments (on- or off-list).  Hence I might believe it is safe to assume there 
is no widespread opposition to harmonizing the network=* tag on all Amtrak 
routes to network=Amtrak without further subdividing values within that 
key-value pair (as below).  Again, the passenger=* tag (as below, with values 
[suburban, regional, national, international]) now denotes the kind of 
passenger service available without subdividing the single network of Amtrak, 
which seems a valid justification for setting all Amtrak routes to be 
network=Amtrak.  We can take further Discussion on this to 
https://wiki.osm.org/wiki/Talk:Amtrak.  Thank you.

While our Amtrak wiki characterizes many route=train relations as "rough," they 
continue to improve (better tagging as above, public_transport:version=1 being 
upgraded to v2, underlying infrastructure route=railway relations created with 
members that are better named and with correct usage=* tags, many platforms 
have been added thanks to the "Add platforms" MapRoulette challenge...).  The 
US has one of the largest, if not THE largest rail and passenger rail networks 
on Earth, it is a large task to improve the many pieces to be "world-class 
passenger train route data."  OSM is well underway towards this goal and 
progress has been steady for several years.  See 
https://wiki.osm.org/wiki/Amtrak and/or 
https://wiki.osm.org/wiki/WikiProject_United_States_railways if you wish to 
participate.

Did you "play with trains" when you were younger?  Please help improve OSM's 
"national train set" in the US:  it's actually rather fun!

SteveA
California


> On Apr 3, 2018, at 11:08 AM, OSM Volunteer stevea  
> wrote:
> 
> I remain listening as to what OSM might best do with the network= tag on 
> Amtrak routes.  Some additional research (Wikipedia) reveals that "Amtrak 
> services fall into three groups:  short-haul service on the Northeast 
> Corridor, state-supported short haul service outside the Northeast Corridor, 
> and long-distance service known within Amtrak as the National Network."  (It 
> is not known what routes are in this "National Network.")  As for 
> "international" routes — there are three which continue into Canada — these 
> are not mentioned, although it may be that these three international routes 
> are considered to be in the National Network.
> 
> Current tagging (passenger=*) of national, regional and suburban (meaning 
> "commuter") seem to correlate quite well with these three groups, and the 
> three international routes are indeed tagged passenger=international.  But 
> that is the passenger=* tag, not the network=* tag.  I still wonder (out 
> loud, here) whether all their network=* tags should be set as simply 
> network=Amtrak or whether these three (four, really) groups should be set as:
> 
> network=Amtrak Commuter (on Amtrak routes which are now set to 
> passenger=suburban, meaning "commuter"),
> network=Amtrak Regional (on Amtrak routes which are now set to 
> passenger=regional),
> network=Amtrak National (on Amtrak routes which are now set to 
> passenger=national),
> network=Amtrak International (on Amtrak routes which are now set to 
> passenger=international).
> 
> Because these seem redundant, given the same information can be gleaned from 
> the passenger=* tag, all Amtrak routes set as:
> 
> network=Amtrak
> 
> is what I'm leaning towards doing.  Although, I do remain listening to 
> opinion/guidance from anybody here on talk-us, including pointing me to 
> additional on-line authoritative data.  We're talking about fifty or fewer 
> route=train relation tags, not huge.  Though, as the Northeast Regionals (and 
> other Amtrak routes) break out of rough public_transport:version=1 and grow 
> into version 2 routes, this number will grow.  This is partly why I want to 
> establish network=* tagging as correct, to get ahead of this curve.
> 
> Thank you for reading,
> SteveA


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

[OSM-talk-fr] statistiques de rapprochement FANTOIR

[Philippe Verdy]

J'ai bien du mal à comprendre comment sont calculées les statistiques de
suiviu du rapprochment BANO/FANTOIR/OSM.

J'ai beau compter et recompter, je n'ai jamais le résultat attendu (malgré
les raffraichissements) et les chiffres donnés sur
http://cadastre.openstreetmap.fr/fantoir/stats_dept.html
ou quand on clique sur une commune de la liste ou quand on regarde le rendu
BANO ne correspondent jamais

D'ailleurs le tableau par département est assez fantaisiste.

J'ai bien l'impression qu'une partie des traitements n'est pas effectuée en
totalité, que les données ne se rafraîchissent pas du tout (ou mal) ou
gardent des données anciennes qui ne sont pas supprimées.

"L'indice 2020" du tableau de suivi par département n'est pas décrit
correctement et en tout cas ne correspond pas du tout à la formule indiquée
dans l'aide.

Bref, le rapprochement BANO fonctionne-t-il réellement? D'ailleur on note
qu'en cliquant "raffrichir la liste" sur la page pour une commune (via son
code INSEE) donne maintenant à chaque fois une erreur: on voit bien
certains changements apparaitre et pas d'autres, sans aucune raison
évidente, comme si la fin des traitements (le traitement des dernières
lignes de données si celles-ci sont traitées par bloc) n'était pas effectué
à cause d'une exception inattendue ou une détection  incorrecte de la fin
des données.

Même sur des toutes petites communes rurales finalisées à 100% le suivi
affiche un tout autre résultat, les lieux-dits bâtis sont tantôt dans la
liste du non-habité (alors qu'ils sont bien habités), ou bien le non-bâti
est listé dans la liste habitée.

Même en complétant les adresses par numéro des voies ne sont toujours pas
rapprochées (alors que l'orthographe est identique, aux
majuscules/minuscules près ou avec les accents français présents dans OSM
mais pas dans le FANTOIR, et qu'il n'y a aucun autre caractère parasite, et
même aucune abréviation (RUE), ni aucun trait d'union ou apostrophe, et que
la référence ref:FR:FANTOIR est renseignée et correspond même à la
géolocalisation proposée.

Bref il y a bien un bogue. Ce rapprochement ne se finit jamais sur aucune
commune, même la plus petite. Sur les grosses communes très peuplées le
suivi est tout bonnement impossible. La carte de rendu BANO est donc assez
farfelue et ne permet pas de mesurer un quelconque progrès. Même en
attendant plusieurs jours ou même des mois après les modidications, les
statuts (couleurs des points) ne bougent jamais.

N'est-ce pas pénalisant pour motiver les contributeurs à faire progresser
BANO et suivre comment il avance et déterminber les zones où les
contributions sont les plus attendues (exemple en Haute-Normandie où il y a
même un "désert" (inhabité???) coincé entre des zones très peuplées. Même
pour Paris, ou dans les communes ayant publiée leurs adresses en Open Data
avec un bon suivi régulier on voit de très nombreuses anomalies, bien plus
que ce qui est réellement dans la base.

BANO est-il condamné à rester juste une expérimentation laissée lettre
morte et abandonnée à elle-même sans aucun suivi de qualité, ne serait-ce
même qu'avec OSM à défaut de remontée et synchro vers la BAN, la Poste,
l'Insee, le cadastre (même dans les communes vectorisées) et les SIG des
collectivités ?

Comment relancer BANO et montrer aux promoteurs de la BAN que BANO peut
réellement aider et aller plus vite et plaier les manques des collectivités
si on n'affiche nous-même aucun progrès et toujours les mêmes anomalies ou
manques alros que les données sont bel et bien déjà dans OSM ?

Comment motiver alors le développement oui l'amélioration d'applications de
géocodage basé sur BANO, et aider à résoudre les cas plus "tordus" et
compliqués quand ils sont noyés dans la masse des erreurs internes à BANO
lui-même qui est incapable même de suivre et fournir des rapports
cohérents. Je pense qu'en l'état BANO reste plus une proposition et qu'en
attendant OSM n'est pas utilisé pour ça et que les acteurs continueront à
utiliser la BAN (elle-même non synchronisée) ou les licences privées de ses
sources. On n'arrivera donc pas à faire converger les sources si chacun
fait dans son coin et ignore les anomalies propres à chaque source, et en
plus ne coorrdonne rien avec les autres.

On aura toujours un aussi mauvais géocodage en France et cela bloque le
développement de pas mal d'applications innovantes qui pourraient en tirer
profit, et même cela ne permet pas d'améliorer la qualité globale d'OSM et
ne facilite pas non plus le rapprochement de données ouvertes (on l'a vu
avec les gros défauts des tentatives d'import de stations essence ou des
données SIREN).

BANO est très important et doit régler ses problèmes pour établir des
rapports réguliers et qui ont un sens et permettent de montrer des
progressions, et ce n'est encore pas du tout le cas.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Su taginfo, è possibile sapere le date creazione dei tag?

[Any File]

2018-04-10 18:17 GMT+02:00 liste DOT girarsi AT posteo DOT eu
:
> Quanto in oggetto per una mia curiosità per capire quando è stato creato un
> tag la prima volta

Ma ti riferisci al primo utilizzo in assoluto (in tutto il mondo) o in
un area da specificare di volta per volta?

Non so come processi i dati taginfo e da quale set di dati usi, ma di
certo non sarebbe un compito da poco che si aggiunge. Inoltre per fare
quello che fa adesso gli basta il set dei dati correnti, mentre per
poter determinare quando è stato utilizzato un tag bisogna avere i
dati comprensivi di tutto lo storico.

C'è anche da dire che una volta ottenuta la data di primo utilizzo di
un tag, questa rimane la stessa nel passare del tempo, pertanto se la
si registra, quando viene fatta l'analisi successiva basta calcolare
la data di primo utilizzo solo dei tag nuovi. Però la prima volta
bisognerebbe fare un lavoro non certo piccolo.

AnyFile

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

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

[Frédéric Rodrigo]

Le 12/04/2018 à 19:03, Jérôme Amagat a écrit :
En ce qui concerne la base des prix des carburants utilisée sur 
osmose, j'ai plusieurs remarque :


déjà, les info de carburants sont sûrement bonnes mais la 
géolocalisation (pour au moins les stations restant à intégrer dans 
osmose) n'est pas toujours bonne voir est très mauvaise.(n'importe où 
dans la commune ou n'importe où le long de la rue). Donc un import de 
masse de ces points, ça serait pas terrible... et l’intégration avec 
osmose est compliqué... il faut chercher avec l'adresse qui est donné 
sur osmose, regarder les stations déjà existantes (il y a de bonne 
chance que la station existe déjà mais comme dans la base elle est mal 
placé osmose ne la met pas dans la catégorie intégration possible)
Osmose propose toutes les stations, il ne sait pas qu'elle est mal placé 
(c'est pour ça qu'il te le demande ;-) )


Dans les mise a jour proposer par osmose, j'ai l'impression qu'on ne 
propose que des ajouts ou des modifications de tags et pas des 
suppressions. Je viens de faire quelques mises à jour avec osmose et 
on m'a proposé pas mal d'ajout de carburant mais pas de suppression. 
Je pense que souvent lorsque dans une station on ajoute un carburant 
c'est en remplacement d'un autre par exemple le sans plomb e10 
remplace le sans plomb normal.
Tu as raison la suppression de tags n'est pas géré (mais ça pourrait, 
aide bienvenue).


Il y a des stations service qui ont changé de ref dans la la base de 
donnée source (je sais pas pourquoi) et des stations qui ont cessés 
d'exister et osmose ne propose pas de supprimer les ref qui ne 
représente plus des stations en fonctionnement.

Osmose, sait le faire, mais ça n'a pas été activé pour les stations.
La ref:FR:prix-carburants vous parait suffisamment stable et 
"importante" pour que ça le soit ?

Ça signalera les stations sans la ref, ou avec une ref inconnue.

Autre chose sur le fonctionnement d'osmose, la source qui est ajouté 
aujourd'hui a une date qui est le 30/08/2017 est ce que les données 
ajoutées sont celles de la base à cette date?

Oui. Il y a justement déjà une mise à jour dans les tuyaux, ça va arriver.
Pour cette analyse la mise à jour automatique des données n'est pas 
supporté (à coder, aide bienvenue).



Frédéric.


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

Re: [Talk-it] Galileo

[Alessandro Palmas]

  
  
Il 12/04/2018 15:50, Francesco Pelullo
  ha scritto:


  

  Il giorno 12 aprile 2018 15:24,
Martin Koppenhoefer 
ha scritto:

  

sent
  from a phone

  
On 12. Apr 2018, at 11:19, Francesco Pelullo 
wrote:

  
  
Penso sarebbe attuabile più semplicemente
  tramite un'app per smartphone. Forse esistono già
  e non lo so.
  
  
  
  

forse su android, le Api di iOS non ti consentono
  di accedere ai dati del chip (Core Location), cfr https://forums.developer.apple.com/thread/19121


  



Si, esiste, e non immaginerai mai dove ho trovato tutte
  le informazioni:
  https://wiki.openstreetmap.org/wiki/RTKLIB
  

Installata e registrato al servizio di correzione
  fornito da ASI, ma adesso non ho tempo di provare.
  

  


In molte regioni c'è il servizio di correzione GNSS gratuito; di
sicuro non c'è in Calabria e Sardegna. Se cercate in rete dovreste
trovare qualche slide dei workshop che Paolo 'Pablo' Dabove ha
tenuto in giro, anche a ArcheoFOSS 2016 a Cagliari e a FOSS4G-IT
2018 di Roma.


Per Android c'era il comodissimo Rtkgps+ ma per carenza di
sviluppatori penso non sia più funzionante per la mancata correzione
dell'ultimo leap second https://www.youtube.com/watch?v=UJBCEeD6ufM

Le librerie RTKLIB linkate sopra sono fortunatamente funzionanti.

Alessandro Ale_Zena_IT

P.S.: qui un link che parla di moduli low cost
https://rtklibexplorer.wordpress.com/2016/11/25/selecting-a-gps-receiver-m8n-vs-m8t/
  


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

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

[Jérôme Amagat]

En ce qui concerne la base des prix des carburants utilisée sur osmose,
j'ai plusieurs remarque :

déjà, les info de carburants sont sûrement bonnes mais la géolocalisation
(pour au moins les stations restant à intégrer dans osmose) n'est pas
toujours bonne voir est très mauvaise.(n'importe où dans la commune ou
n'importe où le long de la rue). Donc un import de masse de ces points, ça
serait pas terrible... et l’intégration avec osmose est compliqué... il
faut chercher avec l'adresse qui est donné sur osmose, regarder les
stations déjà existantes (il y a de bonne chance que la station existe déjà
mais comme dans la base elle est mal placé osmose ne la met pas dans la
catégorie intégration possible)

Dans les mise a jour proposer par osmose, j'ai l'impression qu'on ne
propose que des ajouts ou des modifications de tags et pas des
suppressions. Je viens de faire quelques mises à jour avec osmose et on m'a
proposé pas mal d'ajout de carburant mais pas de suppression. Je pense que
souvent lorsque dans une station on ajoute un carburant c'est en
remplacement d'un autre par exemple le sans plomb e10 remplace le sans
plomb normal.

Il y a des stations service qui ont changé de ref dans la la base de donnée
source (je sais pas pourquoi) et des stations qui ont cessés d'exister et
osmose ne propose pas de supprimer les ref qui ne représente plus des
stations en fonctionnement.

Autre chose sur le fonctionnement d'osmose, la source qui est ajouté
aujourd'hui a une date qui est le 30/08/2017 est ce que les données
ajoutées sont celles de la base à cette date?



Le 12 avril 2018 à 10:19, Christian Quest  a écrit
:

> Les données des stations issues de la base des prix des carburant c'est de
> la donnée chaude... mise à jour plusieurs fois par jour donc très fraîche.
>
> Il manque toutefois certaines infos comme la marque (brand)
>
> Navads c'est de la donnée froide... elle peut servir à compléter certains
> attributs si on est sûr de leur pertinence. brad est un bon candidat,
> opening_hours n'avait pas l'air pertinent (ou alors pour un shop=* associé).
>
> osmose vs import... c'est vraiment deux philosophies qui s'opposent... du
> fait main ou de la machine.
>
> Pourquoi ne pas plutôt utiliser les données navads via osmose sur la
> France avec un mix des données issues des prix des carburants ?
>
>
> Quand je vois 15% d'erreur sur les données vérifiées, je pense qu'on ne
> devrait rien envisager d'automatique avec ces données qui ont besoin d'un
> sérieux contrôle humain avant d'arriver dans OSM.
>
>
> Le 12 avril 2018 à 01:24, marc marc  a écrit :
>
>> 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 

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

[liste DOT girarsi AT posteo DOT eu]

Il 12/04/2018 17:39, Marco Bartalini ha scritto:
a chi possiamo mandare valange di email per far capire quanto è 
importante questo servizio per noi mappatori???



/Marco Bartalini,



Ritengo sia un problema di heatmap, ed heatmap può fare ciò che vuole, è 
un servizio privato ,non dimentichiamocelo.


Ritengo che stiano cercando un modo per mantenere le tracce degli utenti 
private dove vogliono sia così e nel contempo lasciare libre le tracce 
pubbliche, e uesto è un bel lavoro, perchè credo debbano fare in modo 
che sia in tempo reale (compresi i backup? boh!).


Non credo sia solo un problema di autenticazione, come asserito ad 
inizio discussione, la cosa dev'essere parecchio rognosa se ci son di 
mezzo i dati privati, figurati quelli dei militari.





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

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

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

[Marco Bartalini]

a chi possiamo mandare valange di email per far capire quanto è importante
questo servizio per noi mappatori???




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

2018-04-12 9:44 GMT+02:00 liste_girarsi :

> Il 12 Aprile 2018 09:12:26 CEST, Marco Bartalini 
> ha scritto:
> >nemmeno su josm funziona???
> >
> >
> >
> >
> >
> >*Marco Bartalini,marcobartal...@gmail.com *
> >
> >2018-04-11 19:06 GMT+02:00 liste DOT girarsi AT posteo DOT eu <
> >liste.gira...@posteo.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
> >>
>
> no.
>
> --simone girardelli--
> ##
> 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: [OSM-talk-fr] Un nouveau 'concurrent' ?

[Noémie Lehuby]

Bonjour, 

Je travaille chez Qwant sur ces sujets, et je te confirme que ça sera
largement basé sur l'écosystème OSM : 
En plus des données OSM, on utilise (et on contribue) à Kartotherian (le
serveur de tuiles OSM de Wikimedia), OpenMapTiles et Mimirsbrunn (un
géocodeur opensource qui a été présenté au dernier SOTM FR).
On bosse aussi sur un outil pour extraire et typer les boundaries du
monde entier https://github.com/osm-without-borders/cosmogony (je pense
que j'aurais l'occasion d'en reparler ici bientôt) 

L'équipe Qwant Maps sera présente au SOTM à Bordeaux, on vous montrera
tout ça ;)

Noémie

Le 2018-04-12 14:17, PanierAvide a écrit :

> Bonjour, 
> 
> À priori ce sera du OSM, voir cet article :
> https://www.c-s.fr/CS-et-Qwant-nouent-un-partenariat-technologique-dans-le-domaine-de-la-cartographie_a800.html
>  
> 
> Cordialement, 
> 
> Adrien. 
> Le 12/04/2018 à 13:55, Cédric Frayssinet a écrit : 
> 
>> Bonjour à tous,
>> 
>> Avez-vous vu passer cette info : 
>> 
>> https://www.presse-citron.net/qwant-lanti-google-francais-va-lancer-service-de-messagerie/
>> 
>> Assez étonnant de la part de Qwant, à moins qu'ils veuillent utiliser OSM ?
>> 
>> Cédric 
>> 
>> -- 
>> Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté. 
>> 
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> ___
> 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] Galileo

[Francesco Pelullo]

Il giorno 12 aprile 2018 15:24, Martin Koppenhoefer 
ha scritto:

>
>
> sent from a phone
>
> On 12. Apr 2018, at 11:19, Francesco Pelullo  wrote:
>
> Penso sarebbe attuabile più semplicemente tramite un'app per smartphone.
> Forse esistono già e non lo so.
>
>
>
> forse su android, le Api di iOS non ti consentono di accedere ai dati del
> chip (Core Location), cfr https://forums.developer.apple.com/thread/19121
>
>
Si, esiste, e non immaginerai mai dove ho trovato tutte le informazioni:
https://wiki.openstreetmap.org/wiki/RTKLIB

Installata e registrato al servizio di correzione fornito da ASI, ma adesso
non ho tempo di provare.

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

Re: [Talk-it] Galileo

[Martin Koppenhoefer]

sent from a phone

> On 12. Apr 2018, at 11:19, Francesco Pelullo  wrote:
> 
> Penso sarebbe attuabile più semplicemente tramite un'app per smartphone. 
> Forse esistono già e non lo so.


forse su android, le Api di iOS non ti consentono di accedere ai dati del chip 
(Core Location), cfr https://forums.developer.apple.com/thread/19121

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

Re: [Talk-it] Routing ciclismo con VAM

[Andreas Lattmann]

Anche questo:
 https://github.com/poutnikl/Brouter-profiles/wiki

Si, non sarebbe male aggiornare il wiki!


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

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

Re: [OSM-talk-be] Ourthe = path?

[André Pirard]

On 2018-04-12 09:12, Stijn Rombauts wrote:
>> On ‎Thursday‎, ‎April‎ ‎12‎, ‎2018‎ ‎01‎:‎06‎:‎49‎ ‎AM, Gerard
>> Vanderveken  wrote:
>>
>> Goedendag,
>>
>> Hier heeft er eentje bij derivier Ourthe
>> 
>> een highway=path toegevoegd.
>> Is zo een dubbel gebruik van waterway en highway tags korrekt?
>>> Ici on a ajouté un chemin d'autoroute = à la rivière Ourthe.
>>> Une telle double utilisation des voies navigables et des plaques
>>> d'autoroutes est-elle correcte?
>>> (?)
>> Met vriendelijke groeten,
>> Gerard
> Hoi,
>
> Dat is zeker niet correct. Ik denk dat zelfs best die hele changeset
> wordt teruggedraaid. Zie ook bv.
> http://www.openstreetmap.org/way/372287784/history. Hij heeft een hele
> boel objecten diezelfde tags als highway=path e.d. gegeven en dus om
> zeep geholpen...
>> Ce n'est certainement pas correct. Je pense que même tout le
>> changeset est [devrait être?] inversé. Voir aussi, par exemple,
>> http://www.openstreetmap.org/way/372287784/history. Il a donné [à?]
>> tout un tas d'objets qui ont [?] les mêmes tags que highway = path et
>> ainsi de suite et ainsi ...
>
> Mvg,
>
> StijnRR
>
Bon moment présent,

En lisant le change set
, on voit en effet, en
plus, "You added highway=path andother path tags in three forest polygons".
Le mieux est en effet de faire un "revert" mais pas, comme certains en
ont l'habitude, sans avertir l'auteur.
Ne fut-ce que pour lui éviter d'autres erreurs ultérieures.
Est-ce de la distraction ou de l'incompétence (auquel cas se pose de
nouveau la question de la nécessité d'une certification des cartographes)?
Après 3 mois, un revert risque d'effacer d'autres modifications. Il faut
examiner les objets impliqués.
Il est étonnant que de telles erreurs (surtout l'Ourthe) restent 3 mois
sans êtres remarquées.
Merci Gerard.
Je me demande pourquoi utiliser des traces GPX et faire des imprécisions
de 1-2m ou plus alors que nous pouvons tracer le PICC à 20cm près
(extrait ci-dessous).

Cordialement,

André.






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

Re: [OSM-talk-fr] Un nouveau 'concurrent' ?

[PanierAvide]

Bonjour,

À priori ce sera du OSM, voir cet article :
https://www.c-s.fr/CS-et-Qwant-nouent-un-partenariat-technologique-dans-le-domaine-de-la-cartographie_a800.html

Cordialement,

Adrien.


Le 12/04/2018 à 13:55, Cédric Frayssinet a écrit :


Bonjour à tous,

Avez-vous vu passer cette info :

https://www.presse-citron.net/qwant-lanti-google-francais-va-lancer-service-de-messagerie/

Assez étonnant de la part de Qwant, à moins qu'ils veuillent utiliser 
OSM ?


Cédric


--
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma 
brièveté.



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


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

[OSM-talk-fr] Un nouveau 'concurrent' ?

[Cédric Frayssinet]

Bonjour à tous,

Avez-vous vu passer cette info : 

https://www.presse-citron.net/qwant-lanti-google-francais-va-lancer-service-de-messagerie/

Assez étonnant de la part de Qwant, à moins qu'ils veuillent utiliser OSM ?

Cédric 


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

Re: [OSM-talk-be] Ourthe = path?

[Marc Gemis]

In dit geval zal het wel fout zijn, maar bij een rivierbedding die bv.
de helft van het jaar droog staat en dan als pad gebruikt wordt, denk
ik dat de combinatie wel kan.

m.

p.s. is er al iemand bezig met het terugdraaien + contacteren van de mapper ?

2018-04-12 1:06 GMT+02:00 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
>

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

Re: [Talk-it] dataset MISE distributori

[Andrea Musuruane]

Ciao,
 Ho scaricato i dati di oggi dal sito del MISE e ho guardato quelli
nella mia zona.

Ci sono alcune discrepanze. Un nuovo impianto a San Germano V.se non è in
elenco; un impianto a Prarolo è chiuso. Poco male.

Nel campo "Bandiera", si sono persi gli apostrofi (es: "D Amico" ma ce ne
sono anche altri).

Per quanto riguarda le regole di traduzione, non vedo il tag ref:mise nei
dati di output di esempio relativi al Friuli.

Continuo a trovare inutili i tag addr:postcode e addr:city se non si riesce
a importare anche il numero civico e questi hanno senso solo se si
riferiscono al distributore e non ad altre strutture (supermarket, negozio,
bar, ecc).

Sulla mappa online sarebbe utile vedere i numeri civici (ad es. in Friuli
sono stati importati) e anche la possibilità di visualizzare ortofoto
aiuterebbe.

Nella conflation mi sembra che si cerchino solo feature con amenity=fuel.

In questo modo però si perdono quelli etichettati con waterway=fuel:
https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dfuel

Ad esempio, il distributore con ref_id=10670 è già presente in mappa:
https://www.openstreetmap.org/node/3022493614

Ciao,

Andrea




2018-04-10 15:03 GMT+02:00 Cascafico Giovanni :

> Ho aggiustato la pagina wiki [1] dell'import dove troverete una mappa
> delle modifiche per il test sul Friuli Venezia Giulia [2]. Qualche altro
> parere su campi da escludere?
> Lasciate pure qualcosa nella pagina discussione.
>
>
> [2] https://wiki.openstreetmap.org/wiki/Import/
> Catalogue/ItalyFuelStations#Friuli_Venezia_Giulia
>
>
>
>
>
> Il giorno 5 aprile 2018 12:56, Andrea Musuruane  ha
> scritto:
>
>> Ciao,
>>
>> 2018-04-05 10:45 GMT+02:00 Cascafico Giovanni :
>>
>>> ma per il resto prevale una leggera anarchia, per cui appoggerei la
>>> valorizzazione del tag alt_name, piuttosto che il name. Il problema non è
>>> il nome di fantasia, quanto la denominzazione non proprio ordinata, come in
>>> altro campione che riporto della categoria "Altro":
>>>
>>> VIA SAN FRANCESCO CAMMARATA Altro
>>> ciotta michele Altro
>>> Distributore Q8 Patti Giovanni Altro
>>> A. Di Benedetto srl V.le C. Alberto Canicatti Altro
>>> Barbieri energy Altro
>>> Di Benedetto Fabio Altro
>>> ENI 09822 Altro
>>> Esso Cummo Petroli Altro
>>> GIAP Altro
>>> I.D.C. Canicatti' , Viale Giudice Saetta Altro
>>>
>>
>> Continuo a pensare che non ha senso importare questi dati. Non sono
>> omogenei e non portano alcun valore aggiunto.
>>
>>
>>> Altra cosa da considerare, ho dato un'occhiata alle discussioni
>>> sull'import mondiale Navads... i francesi sollevano il dubbio sull'utilità
>>> di importare il postcode: voi che dite?
>>>
>>
>> Il postcode ha senso solo se si importa l'indirizzo completo (ovvero
>> comprensivo di numero civico).
>>
>> L'indirizzo completo ha senso solo se si riferisce al distributore e non
>> ad altre strutture (supermarket, negozio, bar, ecc).
>>
>> Ciao,
>>
>> Andrea
>>
>>
>>
>> ___
>> 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

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

[riccardopastoc...@alice.it]

Vorrei ringraziare, tutte le persone che hanno partecipato a questo mapping, 
abbiamo fatto un gran bel lavoro,finalmente possiamo uscire in ambulanza senza 
la paura di sbagliare strada o numero civico.
Recanati è praticamente tutta mappata... a questo punto sarebbe bello ampliare 
il sogno e mappare anche i territori limitrofi, in particolar modo penso ai 
comuni molto complessi, da raggiungere in ambulanza, perché hanno un centro 
storico fitto e arroccato e una campagna vasta, inizierei da Montelupone, per 
poi passare a Potenza Picena e quindi Montefano.
Io mi prendo il compito di mettere i civici, quello che chiedo è aiutarmi a 
mappare gli edifici e le strade
Grazie anticipatamente a tuttiRiccardo Pastocchi



  Messaggio originale
 
Da: alessandro.pal...@wikimedia.it
 
Data: 11-apr-2018 8.50
 
A: 
 
Ogg: Re: [Talk-it] Convergere su Recanati per 118
 

 
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
 

 



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

Re: [Talk-es] Complemento JOSM para Servicios Web de Catastro

[Carlos Cámara]

Muchísimas gracias, Javier.

Sin duda va a ser muy útil. En cuanto pueda, le echaré un ojo.

Saludos,

Carlos Cámara
http://carloscamara.es

2018-04-12 9:47 GMT+02:00 Javier Sánchez Portero :

> Buenos días
>
> He localizado un complemento que hace justo lo que comentaba en el correo
> anterior pero para República Chéca [1]. Lo he bifurcado en nuestro
> repositorio [2] y con unas pequeñas modificaciones ya funciona para ver las
> fotos de fachada de Catastro. Los cambios ya están combinados en el
> original, pasarán dentro de poco a la versión de desarrollo de JOSM y más
> adelante aparecerá en la versión estable. Cuando eso pase, se podrá
> seleccionar e instalar desde el programa. Mientras tanto, he subido al
> repositorio de Catastro una copia complilada para que lo pueda probar quien
> quiera instalándolo manualmente.
>
> Para instalarlo, descargar este archivo
>
> https://github.com/OSM-es/catastro-import/blob/master/
> pointinfo/pointInfo.jar
>
> Copiarlo en la carpeta 'plugins' de JOSM. La localización depende del
> sistema operativo:
>
> https://josm.openstreetmap.de/wiki/Help/Preferences#Defaultlocation
>
> En JOSM, en preferencias, complementos, seleccionar pointInfo. Aparecerá
> una nueva pestaña en el panel de preferencias, con el icono de una
> interrogación, seleccionar en ella el módulo 'Catastro'.
>
> Para usarlo, con una capa de datos activa, en el menú 'Más herramientas'
> seleccionar la opción 'Información del punto' (tecla rápida Ctrl-Mayús-X).
> Hacer clic en una posición de la pantalla. Aparecerá una ventana con la
> referencia catastral, la dirección postal y un enlace a la foto de fachada.
>
> Javier
>
> [1] https://github.com/mkyral/josm-pointInfo
> [2] https://github.com/OSM-es/josm-pointInfo
>
>
> El 4 de abril de 2018, 15:05, Javier Sánchez Portero  > escribió:
>
>> Hola
>>
>> Llevo tiempo dándole vueltas a alguna forma de hacer accesibles a todo el
>> mundo las fotos de fachada que proporciona Catastro y tenemos autorización
>> para usar [1]. Las fotos son un complemento a la observación sobre el
>> terreno útil para recoger números de portal, estado y tipo de edificios,
>> comprobar su número de plantas, si tiene balcones, forma del techo, si
>> aloja comercios o recursos de interés, ocasionalmente el nombre de la
>> calle, etc, etc.
>>
>> Para acceder a una foto hace falta la referencia catastral de la parcela
>> donde está el edificio. Ahora mismo se puede hacer a través de un fichero
>> que genera el programa CatAtom2Osm [2], pero me gustaría que se pudiera
>> acceder más fácilmente desde JOSM.
>>
>> Catastro proporciona unos servicios web públicos descritos en [3]. El que
>> necesitamos es la Consulta_RCCOOR [4], que devuelve la referencia catastral
>> a partir de las coordenadas. Este es un ejemplo de llamada al servicio [5]
>> y el enlace a la foto de fachada correspondiente [6].
>>
>> El caso de uso sería que en JOSM, haciendo clic con el botón derecho en
>> el mapa, una opción del menú contextual permitiría obtener los datos de la
>> parcela (referencia catastral y dirección postal) y mostrar un enlace para
>> acceder a la foto.
>>
>> Creo que no debe ser muy difícil de programar, aunque no tengo
>> experiencia con complementos de JOSM y me llevará un tiempo documentarme.
>> Si alguien quiere participar en el desarrollo que se ponga en contacto
>> conmigo.
>>
>> Saludos, Javier.
>>
>> [1] https://wiki.openstreetmap.org/wiki/ES:Fuentes_de_datos_pote
>> nciales_de_España#Fotos_de_fachada
>> [2] https://wiki.openstreetmap.org/wiki/ES:Catastro español/Importación
>> de edificios/Conversión de datos/Programa#Acceso_a_fotos_de_fachada
>> [3] http://www.catastro.meh.es/ws/Webservices_Libres.pdf
>> [4] https://ovc.catastro.meh.es/ovcservweb/OVCSWLocalizacionRC/O
>> VCCoordenadas.asmx?op=Consulta_RCCOOR
>> [5] https://ovc.catastro.meh.es/ovcservweb/OVCSWLocalizacionRC/O
>> VCCoordenadas.asmx/Consulta_RCCOOR?SRS=EPSG:4326_
>> X=-16.3071274_Y=28.4273586
>> [6] http://ovc.catastro.meh.es/OVCServWeb/OVCWcfLibres/OVCFotoFa
>> chada.svc/RecuperarFotoFachadaGet?ReferenciaCatastral=2251824CS7425S
>>
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-it] Galileo

[angelo mornata]

Sarebbe interessante sapere qual'è il parametro da cercare per essere certi di 
non fare un'acquisto sbagliato, l'anno scorso ho acquistato un galaxy A5 2017 
che pur avendo 3 antenne perde continuamente il segnale, ne escono dei rilievi 
da schifo


Ps. usavo lo smartphon come doppia rilevazione affiancato a un Garmin.


Grazie

Angelo





Da: Alfredo Gattai 
Inviato: giovedì 12 aprile 2018 07:42
A: openstreetmap list - italiano
Oggetto: Re: [Talk-it] Galileo

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

[Francesco Pelullo]

Il gio 12 apr 2018, 11:11 Martin Koppenhoefer  ha
scritto:

>
>
>> In ogni caso, la correzione dovresti farla sui dati grezzi
>>
>
>
>
> se ricordo bene, l'ultimo GPS "consumer" della Garmin che consentiva
> questo era il GPSMap60 (non il 60CSx).
>

Ci sono versioni homemade di firmware per il 60CSx che consentono di
abilitare varie funzioni. Mai verificato.

>
Penso sarebbe attuabile più semplicemente tramite un'app per smartphone.
Forse esistono già e non lo so.

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

Re: [Talk-it] Galileo

[Martin Koppenhoefer]

2018-04-12 9:36 GMT+02:00 Francesco Pelullo :

>
> In ogni caso, la correzione dovresti farla sui dati grezzi
>



se ricordo bene, l'ultimo GPS "consumer" della Garmin che consentiva questo
era il GPSMap60 (non il 60CSx).

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

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

[Christian Quest]

Les données des stations issues de la base des prix des carburant c'est de
la donnée chaude... mise à jour plusieurs fois par jour donc très fraîche.

Il manque toutefois certaines infos comme la marque (brand)

Navads c'est de la donnée froide... elle peut servir à compléter certains
attributs si on est sûr de leur pertinence. brad est un bon candidat,
opening_hours n'avait pas l'air pertinent (ou alors pour un shop=* associé).

osmose vs import... c'est vraiment deux philosophies qui s'opposent... du
fait main ou de la machine.

Pourquoi ne pas plutôt utiliser les données navads via osmose sur la France
avec un mix des données issues des prix des carburants ?


Quand je vois 15% d'erreur sur les données vérifiées, je pense qu'on ne
devrait rien envisager d'automatique avec ces données qui ont besoin d'un
sérieux contrôle humain avant d'arriver dans OSM.


Le 12 avril 2018 à 01:24, marc marc  a écrit :

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



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

Re: [Talk-it] Galileo

[Francesco Pelullo]

Il giorno 12 aprile 2018 09:46, Edoardo Yossef Marascalchi <
e.marascal...@gmail.com> ha scritto:

> esatto, ma se ci sono mappatori in giro per l'itlia che creano la rete di
> ricevitori abbastsnza capillare, è possibile realizzare anche una app che
> faccia la correzione in tempo quasi reale (nel arco di 1-2 secondi).
>

Si, capisco, non sarebbe male.
Pensa che bello sarebbe avere qualcosa del genere in un mapping party.

Su Linux c'era gpsd che consentiva qualcosa del genere, non credo sia
impossibile da realizzarsi.

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

Re: [Talk-it] Galileo

[Martin Koppenhoefer]

sent from a phone

> On 12. Apr 2018, at 07:42, Alfredo Gattai  wrote:
> 
> 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).


quando parliamo di precisione, ci riferiamo a rilevamenti gps/galileo/glonass o 
anche agps? Submetrica non lo so, ma con una mappa di access points e wlan si 
può ottenere una buona precisione anche senza antenne esterne o segnali da 
satelliti in generale.

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

Re: [Talk-es] Complemento JOSM para Servicios Web de Catastro

[Javier Sánchez Portero]

Buenos días

He localizado un complemento que hace justo lo que comentaba en el correo
anterior pero para República Chéca [1]. Lo he bifurcado en nuestro
repositorio [2] y con unas pequeñas modificaciones ya funciona para ver las
fotos de fachada de Catastro. Los cambios ya están combinados en el
original, pasarán dentro de poco a la versión de desarrollo de JOSM y más
adelante aparecerá en la versión estable. Cuando eso pase, se podrá
seleccionar e instalar desde el programa. Mientras tanto, he subido al
repositorio de Catastro una copia complilada para que lo pueda probar quien
quiera instalándolo manualmente.

Para instalarlo, descargar este archivo

https://github.com/OSM-es/catastro-import/blob/master/pointinfo/pointInfo.jar

Copiarlo en la carpeta 'plugins' de JOSM. La localización depende del
sistema operativo:

https://josm.openstreetmap.de/wiki/Help/Preferences#Defaultlocation

En JOSM, en preferencias, complementos, seleccionar pointInfo. Aparecerá
una nueva pestaña en el panel de preferencias, con el icono de una
interrogación, seleccionar en ella el módulo 'Catastro'.

Para usarlo, con una capa de datos activa, en el menú 'Más herramientas'
seleccionar la opción 'Información del punto' (tecla rápida Ctrl-Mayús-X).
Hacer clic en una posición de la pantalla. Aparecerá una ventana con la
referencia catastral, la dirección postal y un enlace a la foto de fachada.

Javier

[1] https://github.com/mkyral/josm-pointInfo
[2] https://github.com/OSM-es/josm-pointInfo


El 4 de abril de 2018, 15:05, Javier Sánchez Portero 
escribió:

> Hola
>
> Llevo tiempo dándole vueltas a alguna forma de hacer accesibles a todo el
> mundo las fotos de fachada que proporciona Catastro y tenemos autorización
> para usar [1]. Las fotos son un complemento a la observación sobre el
> terreno útil para recoger números de portal, estado y tipo de edificios,
> comprobar su número de plantas, si tiene balcones, forma del techo, si
> aloja comercios o recursos de interés, ocasionalmente el nombre de la
> calle, etc, etc.
>
> Para acceder a una foto hace falta la referencia catastral de la parcela
> donde está el edificio. Ahora mismo se puede hacer a través de un fichero
> que genera el programa CatAtom2Osm [2], pero me gustaría que se pudiera
> acceder más fácilmente desde JOSM.
>
> Catastro proporciona unos servicios web públicos descritos en [3]. El que
> necesitamos es la Consulta_RCCOOR [4], que devuelve la referencia catastral
> a partir de las coordenadas. Este es un ejemplo de llamada al servicio [5]
> y el enlace a la foto de fachada correspondiente [6].
>
> El caso de uso sería que en JOSM, haciendo clic con el botón derecho en el
> mapa, una opción del menú contextual permitiría obtener los datos de la
> parcela (referencia catastral y dirección postal) y mostrar un enlace para
> acceder a la foto.
>
> Creo que no debe ser muy difícil de programar, aunque no tengo experiencia
> con complementos de JOSM y me llevará un tiempo documentarme. Si alguien
> quiere participar en el desarrollo que se ponga en contacto conmigo.
>
> Saludos, Javier.
>
> [1] https://wiki.openstreetmap.org/wiki/ES:Fuentes_de_datos_
> potenciales_de_España#Fotos_de_fachada
> [2] https://wiki.openstreetmap.org/wiki/ES:Catastro español/Importación
> de edificios/Conversión de datos/Programa#Acceso_a_fotos_de_fachada
> [3] http://www.catastro.meh.es/ws/Webservices_Libres.pdf
> [4] https://ovc.catastro.meh.es/ovcservweb/OVCSWLocalizacionRC/
> OVCCoordenadas.asmx?op=Consulta_RCCOOR
> [5] https://ovc.catastro.meh.es/ovcservweb/OVCSWLocalizacionRC/
> OVCCoordenadas.asmx/Consulta_RCCOOR?SRS=EPSG:4326&
> Coordenada_X=-16.3071274_Y=28.4273586
> [6] http://ovc.catastro.meh.es/OVCServWeb/OVCWcfLibres/OVCFotoFachada.svc/
> RecuperarFotoFachadaGet?ReferenciaCatastral=2251824CS7425S
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-it] Galileo

[Edoardo Yossef Marascalchi]

esatto, ma se ci sono mappatori in giro per l'itlia che creano la rete di
ricevitori abbastsnza capillare, è possibile realizzare anche una app che
faccia la correzione in tempo quasi reale (nel arco di 1-2 secondi).

2018-04-12 10:36 GMT+03:00 Francesco Pelullo :

>
>
> Il gio 12 apr 2018, 09:28 Edoardo Yossef Marascalchi <
> e.marascal...@gmail.com> ha scritto:
>
>> Io invece vorrei chiedervi una cosa diversa:
>> perdonatemi ma non mi viene in mente il termine corretto quindi cercate
>> di capirmi, quanto sarebbe complicato costruirsi la rete di ricevitori gps
>> collocati in posizione certa per correggere gli errori di rilevamento di
>> quelli in movimento?
>> Ormai siamo molti e non dovrebbe essere troppo difficile avere un numero
>> sufficiente di postazioni attivate e collegate in RT ad un server centrale
>> da cui condividere le rilevazioni
>>
>
> Esistono vari servizi in rete che offrono g gratuitamente proprio questo.
>
> Prova a cercare ad esempio GNSS Puglia.
>
> In ogni caso, la correzione dovresti farla sui dati grezzi, in epoca
> successiva e con un riferimento molto vicino, nell'ordine di qualche decina
> di km.
>
> Ciao
> /niubii/
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>


-- 
Edoardo Yossef Marascalchi
skype: asca_edom
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[liste_girarsi]

Il 12 Aprile 2018 09:12:26 CEST, Marco Bartalini  ha 
scritto:
>nemmeno su josm funziona???
>
>
>
>
>
>*Marco Bartalini,marcobartal...@gmail.com *
>
>2018-04-11 19:06 GMT+02:00 liste DOT girarsi AT posteo DOT eu <
>liste.gira...@posteo.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
>>

no.

--simone girardelli--
##
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.

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

Re: [Talk-it] Galileo

[Francesco Pelullo]

Il gio 12 apr 2018, 09:28 Edoardo Yossef Marascalchi <
e.marascal...@gmail.com> ha scritto:

> Io invece vorrei chiedervi una cosa diversa:
> perdonatemi ma non mi viene in mente il termine corretto quindi cercate di
> capirmi, quanto sarebbe complicato costruirsi la rete di ricevitori gps
> collocati in posizione certa per correggere gli errori di rilevamento di
> quelli in movimento?
> Ormai siamo molti e non dovrebbe essere troppo difficile avere un numero
> sufficiente di postazioni attivate e collegate in RT ad un server centrale
> da cui condividere le rilevazioni
>

Esistono vari servizi in rete che offrono g gratuitamente proprio questo.

Prova a cercare ad esempio GNSS Puglia.

In ogni caso, la correzione dovresti farla sui dati grezzi, in epoca
successiva e con un riferimento molto vicino, nell'ordine di qualche decina
di km.

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

Re: [Talk-it] Galileo

[Edoardo Yossef Marascalchi]

Io invece vorrei chiedervi una cosa diversa:
perdonatemi ma non mi viene in mente il termine corretto quindi cercate di
capirmi, quanto sarebbe complicato costruirsi la rete di ricevitori gps
collocati in posizione certa per correggere gli errori di rilevamento di
quelli in movimento?
Ormai siamo molti e non dovrebbe essere troppo difficile avere un numero
sufficiente di postazioni attivate e collegate in RT ad un server centrale
da cui condividere le rilevazioni



2018-04-12 10:20 GMT+03:00 Francesco Pelullo :

>
>
> Il giorno 12 aprile 2018 08:20, Alfredo Gattai 
> ha scritto:
>
>> Hdop e Vdop ottimali, non c'e' dubbio, ma non vuol dire precisione
>> submetrica, non c'e' relazione diretta.
>>
>>
> Si, ma quei valori (H/VDOP) su uno smartphone non abilitato per Galileo
> assumono valori ben più alti, nell'ordine dei metri.
> So perfettamente che il valore mostrato abbia funzione puramente
> indicativa (non è certo assumibile come valore assoluto), ma giusto per
> chiarire la supercazzola di questo thread :-) mi sembra che Galileo possa
> portare a miglioramenti significativi.
>
> Anche se siamo ancora ad una precisione stimabile in metri, direi che lo
> smartphone che sto per acquistare dovrà essere abilitato Galileo.
>
> Come un Antani!
> :-)
>
> Ciao
> /niubii/
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>


-- 
Edoardo Yossef Marascalchi
skype: asca_edom
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Galileo

[Alfredo Gattai]

Questo e' certo. Se lo devi conprare ora certamente con Galileo!

Il Gio 12 Apr 2018, 09:21 Francesco Pelullo  ha
scritto:

>
>
> Il giorno 12 aprile 2018 08:20, Alfredo Gattai 
> ha scritto:
>
>> Hdop e Vdop ottimali, non c'e' dubbio, ma non vuol dire precisione
>> submetrica, non c'e' relazione diretta.
>>
>>
> Si, ma quei valori (H/VDOP) su uno smartphone non abilitato per Galileo
> assumono valori ben più alti, nell'ordine dei metri.
> So perfettamente che il valore mostrato abbia funzione puramente
> indicativa (non è certo assumibile come valore assoluto), ma giusto per
> chiarire la supercazzola di questo thread :-) mi sembra che Galileo possa
> portare a miglioramenti significativi.
>
> Anche se siamo ancora ad una precisione stimabile in metri, direi che lo
> smartphone che sto per acquistare dovrà essere abilitato Galileo.
>
> Come un Antani!
> :-)
>
> Ciao
> /niubii/
>
> ___
> 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

[Francesco Pelullo]

Il giorno 12 aprile 2018 08:20, Alfredo Gattai 
ha scritto:

> Hdop e Vdop ottimali, non c'e' dubbio, ma non vuol dire precisione
> submetrica, non c'e' relazione diretta.
>
>
Si, ma quei valori (H/VDOP) su uno smartphone non abilitato per Galileo
assumono valori ben più alti, nell'ordine dei metri.
So perfettamente che il valore mostrato abbia funzione puramente indicativa
(non è certo assumibile come valore assoluto), ma giusto per chiarire la
supercazzola di questo thread :-) mi sembra che Galileo possa portare a
miglioramenti significativi.

Anche se siamo ancora ad una precisione stimabile in metri, direi che lo
smartphone che sto per acquistare dovrà essere abilitato Galileo.

Come un Antani!
:-)

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

Re: [Talk-it] Routing ciclismo con VAM

[Francesco Pelullo]

Il giorno 12 aprile 2018 09:12, Volker Schmidt  ha
scritto:

> Per che non nel wiki?
>
> 2018-04-12 8:30 GMT+02:00 Andreas Lattmann :
>
>> Credo che comincerò a scrivere il mio diario OSM con tutti gli strumenti
>> basati su OSM che trovo. Credo che possa avere qualche utilità. 
>>
>>
>
Stavo per scriverlo io.
Per favore, quando lo scriverai, aggiungici anche il link a questo sito dal
quale è possibile scaricare il profilo di routing ottimizzato per mtb:

https://github.com/zossebart/brouter-mtb

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

Re: [OSM-talk-be] Ourthe = path?

[Stijn Rombauts]

 Hoi,
Dat is zeker niet correct. Ik denk dat zelfs best die hele changeset wordt 
teruggedraaid. Zie ook bv. http://www.openstreetmap.org/way/372287784/history. 
Hij heeft een hele boel objecten diezelfde tags als highway=path e.d. gegeven 
en dus om zeep geholpen...



Mvg,




StijnRR


On ‎Thursday‎, ‎April‎ ‎12‎, ‎2018‎ ‎01‎:‎06‎:‎49‎ ‎AM, Gerard Vanderveken 
 wrote:  
 
  Goedendag,

Hier heeft er eentje bij derivier 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
  ___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Marco Bartalini]

nemmeno su josm funziona???





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

2018-04-11 19:06 GMT+02:00 liste DOT girarsi AT posteo DOT eu <
liste.gira...@posteo.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
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Routing ciclismo con VAM

[Volker Schmidt]

Per che non nel wiki?

2018-04-12 8:30 GMT+02:00 Andreas Lattmann :

> Credo che comincerò a scrivere il mio diario OSM con tutti gli strumenti
> basati su OSM che trovo. Credo che possa avere qualche utilità. 
>
> 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] Routing ciclismo con VAM

[Andreas Lattmann]

Credo che comincerò a scrivere il mio diario OSM con tutti gli strumenti basati 
su OSM che trovo. Credo che possa avere qualche utilità. 

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

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

Re: [Talk-it] Galileo

[Alfredo Gattai]

Hdop e Vdop ottimali, non c'e' dubbio, ma non vuol dire precisione
submetrica, non c'e' relazione diretta.

Il Gio 12 Apr 2018, 07:57 Francesco Pelullo  ha
scritto:

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