Re: [Talk-it] MAPS.ME maggior diffusione OSM inizio nuovi problemi... Seri!

[Andrea Lattmann]

>sarebbe ottimo, se il 10% degli >utilizzatori di mapsme diventesse >mappatori 
>osm.  mapsme è tra le app >più popolari al mondo...

me ne sono accorto. Non pensavo fosse così popolare. :-)

Andrea Lattmann

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

[Talk-us] Whole-US Garmin Map update - 2016-06-01

[Dave Hansen]

These are based off of Lambertus's work here:

http://garmin.openstreetmap.nl

If you have questions or comments about these maps, please feel
free to ask.  However, please do not send me private mail.  The
odds are, someone else will have the same questions, and by
asking on the talk-us@ list, others can benefit.

Downloads:

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2016-06-01

Map to visualize what each file contains:


http://daveh.dev.openstreetmap.org/garmin/Lambertus/2016-06-01/kml/kml.html


FAQ



Why did you do this?

I wrote scripts to joined them myself to lessen the impact
of doing a large join on Lambertus's server.  I've also
cut them in large longitude swaths that should fit conveniently
on removable media.  

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2016-06-01

Can or should I seed the torrents?

Yes!!  If you use the .torrent files, please seed.  That web
server is in the UK, and it helps to have some peers on this
side of the Atlantic.

Why is my map missing small rectangular areas?

There have been some missing tiles from Lambertus's map (the
red rectangles),  I don't see any at the moment, so you may
want to update if you had issues with the last set.

Why can I not copy the large files to my new SD card?

If you buy a new card (especially SDHC), some are FAT16 from
the factory.  I had to reformat it to let me create a >2GB
file.

Does your map cover Mexico/Canada?

Yes!!  I have, for the purposes of this map, annexed Ontario
in to the USA.  Some areas of North America that are close
to the US also just happen to get pulled in to these maps.
This might not happen forever, and if you would like your
non-US area to get included, let me know. 

-- Dave


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

Re: [Talk-us] Import in progress: NYC DEP Watershed Recreation Areas

[Kevin Kenny]

I just realized on further inspection that 'protect_class' on the
protected areas is erroneously spelt out 'protection_class'. I think
that this proves that no matter how careful one is, at least one bug
slips past when a system 'goes live.'

I'll correct the typo in the other 39 townships, and correct it
manually in the 25 places it appears in this changeset. I'm going to
defer the correction in the upload until I'm resuming uploading. so as
to avoid complicating a revert should one prove necessary.


On Sat, Jun 4, 2016 at 11:00 PM, Kevin Kenny
 wrote:
> I've now begun the import for the NYC DEP Watershed Recreation Areas.
>
> According to the plan, I've imported the units that lie in a single
> township out of the forty townships that contain these areas. (Town of
> Andes - the first of the list in alphabetical order). The changeset
> for this activity is https://www.openstreetmap.org/changeset/39807853
>
> JOSM uploaded the areas without errors or warnings.
>
> A quick visual check at least appears plausible. I notice several things:
>
> There are numerous cases where the parcel is clearly supposed to be at
> a fixed setback from a highway. Some of these do not align to the
> highway. In every case that I checked visually against Bing Aerial.
> New York City is right and TIGER is wrong. Virtually all the highways
> in the area are unreviewed TIGER ways.
>
> The alignment of the protected_area boundaries with the New York State
> lands is rather untidy. There has been considerably interagency
> coordination of these in recent years, and the current version of
> 'NYSDEP Lands' is in considerably better alignment with the New York
> City data. That misalignment is one of a number of reasons why I think
> that the 'NYSDEP Lands' file should be reimported, and not just have
> its tagging fixed by a mechanical edit. I'm still working on a plan
> for this. I think I may be close to a breakthrough on techniques for
> semiautomatic repair of the sort of mildly inconsistent cadastral data
> that we have here.
>
> According to the plan, I'll now stop for a week, so that if there are
> any screams of horror, there will be only a single changeset,
> consisting only of added objects, to be reverted.

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

[Talk-us] Import in progress: NYC DEP Watershed Recreation Areas

[Kevin Kenny]

I've now begun the import for the NYC DEP Watershed Recreation Areas.

According to the plan, I've imported the units that lie in a single
township out of the forty townships that contain these areas. (Town of
Andes - the first of the list in alphabetical order). The changeset
for this activity is https://www.openstreetmap.org/changeset/39807853

JOSM uploaded the areas without errors or warnings.

A quick visual check at least appears plausible. I notice several things:

There are numerous cases where the parcel is clearly supposed to be at
a fixed setback from a highway. Some of these do not align to the
highway. In every case that I checked visually against Bing Aerial.
New York City is right and TIGER is wrong. Virtually all the highways
in the area are unreviewed TIGER ways.

The alignment of the protected_area boundaries with the New York State
lands is rather untidy. There has been considerably interagency
coordination of these in recent years, and the current version of
'NYSDEP Lands' is in considerably better alignment with the New York
City data. That misalignment is one of a number of reasons why I think
that the 'NYSDEP Lands' file should be reimported, and not just have
its tagging fixed by a mechanical edit. I'm still working on a plan
for this. I think I may be close to a breakthrough on techniques for
semiautomatic repair of the sort of mildly inconsistent cadastral data
that we have here.

According to the plan, I'll now stop for a week, so that if there are
any screams of horror, there will be only a single changeset,
consisting only of added objects, to be reverted.

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

Re: [Talk-us] Best practices for dealing with old TIGER tags?

[Harald Kliems]

All these discussions are the reason why I almost never touch the highway=*
tag and rather add surface=* or other descriptive tags to TIGER roads.
There just isn't any consensus and many good reasons for many positions
about residential, unclassified, track, etc.

 Harald.

On Sat, Jun 4, 2016 at 5:50 PM Eric Ladner  wrote:

> On Sat, Jun 4, 2016 at 5:01 PM Kevin Kenny 
> wrote:
>
>> I'm usually talking about mapping in much more remote areas, and I've
>> been using 'track' more to denote more road quality. In some of the
>> places I go, there are public rights-of-way that haven't been
>> maintained by the counties in decades, that would still be lawful to
>> drive on if you had a vehicle that could do it. They range from
>> "completely grown to trees but you can most likely ride an ATV"
>> through "mostly used for forestry, and high-clearance vehicles
>> shouldn't have much problem, but don't try it in a passenger car" to
>> "pea gravel and sugar sand that someone grades once a season, used as
>> an auto road in the summer and a snowmobile track in the winter."
>
>
> Isn't that what "tracktype=gradeX" is for?   The first case would be
> highway=track; tracktype=grade5, the second probably tracktype=grade2 and
> the last tracktype=grade1.  They're all highway=track (utility/farm vehicle
> access), but just different grades (from grassy cow paths up to hard packed
> gravel/clay roads that are, in some places, probably nicer than most back
> water county paved roads.
>
> You mentioned forestry, so naturally I think of logging roads.
> Technically it's public land, so there's no restriction to access, but for
> all intents and purposes, they are highway=track.
>
> The
>> first is "highway=path" with appropriate notations for what uses are
>> permitted, the second is "highway=track" (I could add "access=yes" but
>> I thought that was the default for all highways); the third I'm less
>> sure about, and I'm inconsistent between "track" and "unclassified"
>> (with restrictions of 15 May-15 October, or whatever the season is).
>> These are all roads where I have to keep reassuring my city-bred wife,
>> "yes, this is a public road, even if it looks like an abandoned
>> driveway!" when driving a 4WD down one.
>>
>
> General public access roads, though, in extreme rural areas where the road
> is not what city folks would call a road -- probably would be unclassified
> with a "surface" qualifier (unpaved, compacted, dirt, earth, whatever).
>
> The description for highway=path says it's generally used for
> non-motorized vehicles.  I'd prefer highway=unclassified, also with a
> surface qualifier.  But...
>
> ... I'm not bashing anybody over the head with my opinion, just stating an
> alternate point of view.  I'm fine with whatever anybody wants to do as
> long as it's consistent and has some kind of rationale behind it.
>
> E
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-be] WMS layer SPW(Wallonie) PICC disponible dans JOSM est obsolete

[André Pirard]

  
  
On 2016-06-05 00:51, Erik B wrote:


  
  Les données géographiques SPW PICC disponible comme layer dans
  JOSM ne fonctionnent plus.
  Message sur Géoportail de la Wallonie
  :
  CETTE DONNÉE  EST DÉSACTIVÉE DÉFINITIVEMENT DEPUIS LE 31 MAI 2016
  ; 
  IL N'EST PLUS POSSIBLE DE L'OBTENIR ; VEUILLEZ UTILISER LA
  NOUVELLE VERSION DU PICC. 
  
  Est-ce que cette nouvelle version est disponible? Et avec quel
  lien?

Je vais tenter de remédier à ça demain soir.

Cheers



  

  André.

  



  


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

Re: [Talk-de] EnBW erneuert Ladesäulen für Elektroautos

[Angie]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 04.06.2016 um 20:04 schrieb Joachim Kast:
> 
>> 
>> 
>>> Schaut bei Gelegenheit in eurer Nähe ob die Daten noch aktuell sind.
>> 
>> 
> 
> OpenStreetMap ist eine Geodatenbank. Die verschiedenen Kartenersteller 
> entscheiden, was sie darstellen und was nicht. Die Ladestationen werden auf
> der Hauptkarte nicht angezeigt,

Aha, die öffentliche Toilette daneben aber schon - OK, man muss schließlich
Prioritäten setzen.

Die Tankstellen einige 100m weiter SW mit "richtigen Sprit" werden aber schon
auch gerendert. Auch OK, E-Autos sind eh noch nicht so viele unterwegs.

MfG Angie

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAldTYYoACgkQbWutCqbzQO2ZZQCeOvZu6KUQzYyfqWnEh3lgfElL
E1UAoMA4isXu+RJMbgSaSEM5SdfarCE1
=z9g3
-END PGP SIGNATURE-

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

[OSM-talk-be] WMS layer SPW(Wallonie) PICC disponible dans JOSM est obsolete

[Erik B]

Les données géographiques SPW PICC disponible comme layer dans JOSM ne 
fonctionnent plus.

Message sur Géoportail de la Wallonie  :
CETTE DONNÉE  EST DÉSACTIVÉE DÉFINITIVEMENT DEPUIS LE 31 MAI 2016 ;
IL N'EST PLUS POSSIBLE DE L'OBTENIR ; VEUILLEZ UTILISER LA NOUVELLE 
VERSION DU PICC.


Est-ce que cette nouvelle version est disponible? Et avec quel lien?

Erik


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

Re: [Talk-us] Best practices for dealing with old TIGER tags?

[Eric Ladner]

On Sat, Jun 4, 2016 at 5:01 PM Kevin Kenny 
wrote:

> I'm usually talking about mapping in much more remote areas, and I've
> been using 'track' more to denote more road quality. In some of the
> places I go, there are public rights-of-way that haven't been
> maintained by the counties in decades, that would still be lawful to
> drive on if you had a vehicle that could do it. They range from
> "completely grown to trees but you can most likely ride an ATV"
> through "mostly used for forestry, and high-clearance vehicles
> shouldn't have much problem, but don't try it in a passenger car" to
> "pea gravel and sugar sand that someone grades once a season, used as
> an auto road in the summer and a snowmobile track in the winter."


Isn't that what "tracktype=gradeX" is for?   The first case would be
highway=track; tracktype=grade5, the second probably tracktype=grade2 and
the last tracktype=grade1.  They're all highway=track (utility/farm vehicle
access), but just different grades (from grassy cow paths up to hard packed
gravel/clay roads that are, in some places, probably nicer than most back
water county paved roads.

You mentioned forestry, so naturally I think of logging roads.  Technically
it's public land, so there's no restriction to access, but for all intents
and purposes, they are highway=track.

The
> first is "highway=path" with appropriate notations for what uses are
> permitted, the second is "highway=track" (I could add "access=yes" but
> I thought that was the default for all highways); the third I'm less
> sure about, and I'm inconsistent between "track" and "unclassified"
> (with restrictions of 15 May-15 October, or whatever the season is).
> These are all roads where I have to keep reassuring my city-bred wife,
> "yes, this is a public road, even if it looks like an abandoned
> driveway!" when driving a 4WD down one.
>

General public access roads, though, in extreme rural areas where the road
is not what city folks would call a road -- probably would be unclassified
with a "surface" qualifier (unpaved, compacted, dirt, earth, whatever).

The description for highway=path says it's generally used for non-motorized
vehicles.  I'd prefer highway=unclassified, also with a surface qualifier.
But...

... I'm not bashing anybody over the head with my opinion, just stating an
alternate point of view.  I'm fine with whatever anybody wants to do as
long as it's consistent and has some kind of rationale behind it.

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

Re: [Talk-at] renaturierung traisen / mündung donau

[Stefan Kopetzky]

On 2016-06-03 22:58, Rainer Fügenstein wrote:
> falls also jemand eine idee hat, wie man die aufnehmen kann ...

Mit einer Zille abfahren oder mit einer Drohne Fotos machen und an
Fixpunkten ausrichten. Ich fürcht es ist einfacher auf ein Update der
Luftbilder zu warten...

LG,
Stefan

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

Re: [Talk-it] MAPS.ME maggior diffusione OSM inizio nuovi problemi... Seri!

[Martin Koppenhoefer]

sent from a phone

> Il giorno 04 giu 2016, alle ore 16:04, Andrea Albani  ha 
> scritto:
> 
> Ci sarà sicuramente una quota di utilizzatori di maps.me che vanno oltre, ma 
> penso che il 90% di questi "casual mappers"  siano più attirati dalle 
> potenzialità di un app di navigazione offline che dal resto.


sarebbe ottimo, se il 10% degli utilizzatori di mapsme diventesse mappatori 
osm.  mapsme è tra le app più popolari al mondo...

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

[Talk-cz] Jáma - jak otagovat?

[Marián Kyral]

Ahoj,
dnes jsme na výletě u Valmezu narazili na jámy po plánovaných věterných
elektrárnách. Stavba se nakonec neuskutečnila, stavební úřad ji zarazil.
Ale jámy zůstaly. Zatím marně hledám, Jak je mám otagovat?

cutting=yes?

Nějaký tip?

Diky
Marián

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

Re: [Talk-it] MAPS.ME maggior diffusione OSM inizio nuovi problemi... Seri!

[Martin Koppenhoefer]

sent from a phone

> Il giorno 04 giu 2016, alle ore 20:06, Alecs  
> ha scritto:
> 
> Almeno ora abbiamo qualche name:zh in più che non dà
> fastidio anzi, gli ultimi due li ho cancellati perchè, se prendo per buono i
> risultati che mi dà google senza sapere il cinese



hai cancellato dei nomi in cinese perché Google sembrava dire che significavano 
altre cose? Per me non dovresti toccare i tags in cinese se non lo sai...

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

Re: [Talk-us] Best practices for dealing with old TIGER tags?

[Kevin Kenny]

I'm usually talking about mapping in much more remote areas, and I've
been using 'track' more to denote more road quality. In some of the
places I go, there are public rights-of-way that haven't been
maintained by the counties in decades, that would still be lawful to
drive on if you had a vehicle that could do it. They range from
"completely grown to trees but you can most likely ride an ATV"
through "mostly used for forestry, and high-clearance vehicles
shouldn't have much problem, but don't try it in a passenger car" to
"pea gravel and sugar sand that someone grades once a season, used as
an auto road in the summer and a snowmobile track in the winter." The
first is "highway=path" with appropriate notations for what uses are
permitted, the second is "highway=track" (I could add "access=yes" but
I thought that was the default for all highways); the third I'm less
sure about, and I'm inconsistent between "track" and "unclassified"
(with restrictions of 15 May-15 October, or whatever the season is).
These are all roads where I have to keep reassuring my city-bred wife,
"yes, this is a public road, even if it looks like an abandoned
driveway!" when driving a 4WD down one.

These are all legally public highways. Many of them are of a
classification that allows a landowner to gate them to restrain
livestock while allowing the stock to cross the road, as long as the
gate is left unlocked so that a traveler can pass, so they might be
gated and still public.



On Sat, Jun 4, 2016 at 12:23 PM, Greg Troxel  wrote:
>
> Eric Ladner  writes:
>
>> On Sat, Jun 4, 2016 at 5:58 AM Greg Troxel  wrote:
>>
>>>
>>> Kevin Kenny  writes:
>>>
>>> > OK, 'residential' if it looks like 'subdivision', 'unclassified'
>>> > otherwise (as long as it's drivable in, say, my daughter's car rather
>>> > than my 4-wheeler). Got it.
>>>
>>> I also see a distinction between residential/unclassified as denoting a
>>> legal road (around me, carved-out parcel wise from the surrounding land)
>>> vs track and some service denoting a non-legal-road.  However, others
>>> see the physical and legal attributes as separate.
>>>
>> My understanding of the description of "unclassified" is unclassified is a
>> step between residential and tertiary.   It's a connecting road, minor
>> connector, whatever, that doesn't have residential on it, but it's not high
>> enough in classification to make it a tertiary road.
>
> I agree with that notion.
>
>> I usually use it for roads in industrial complexes, loops around malls,
>> business complexes, or other connectors/roads where there's no obvious
>> residential around.
>
> Mostly agree, but I only use it for legal roads, not driveways or
> private roads.  Meaning someplace where (in new england) it's legally
> separate and the public has a right of access.

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

Re: [OSM-talk-fr] ERDF (et RFF) ont changé de nom

[osm . sanspourriel]

Le 2016-06-04 à 20:44, DH - dhel...@free.fr a écrit :


Le 04/06/2016 19:43, osm.sanspourr...@spamgourmet.com a écrit :

le 2016-06-04 à 19:18, DH - dhel...@free.fr a écrit :

Le RFN n'est pas un réseau de voies ferrés donc ? what else ?
Un réseau implique usuellement une topologie, là c'est juste "est 
opéré par". 
Ah bon ? Selon toi, les trains soit, sortent du RFN le temps de 
trouver le prochain tronçon, soit demande la permission à un autre 
opérateur (lequel ?) pour retraper le RFN ?
Je te rassures, il n'en est rien, le RFN EST topologique. Et il n'est 
pas "juste" opéré par ; juridiquement SNCF Réseau en est aussi le 
propriétaire (avec tous les emmerdements qui vont avec)
Contrairement à Endis qui n'est que le concessionnaire au même titre que 
VéOLia et consorts pour l'eau.
Oui, bien-sûr RFN est un réseau au sens topologique, ce que je veux dire 
c'est que si tu mets tout en vrac dans une relation, tu n'as plus grand 
chose. En tous cas pas un réseau.


Jérôme, même sur la ligne Carhaix-Guingamp, qui n'est pas opérée par la 
SNCF le rail est opéré par SNCF Réseaux.


> A savoir que dans la plupart des cas, on dispose que de la ligne dans 
osm et non les voies. Donc difficile de mettre les bons termes.

Heu, j'ai l'impression qu'actuellement en France on a les voies.

Est-ce une bonne pratique de mettre systématiquement oneway=no sur 
toute la voirie standard ?
oui, car il a des tronçons à voie unique. De plus si par tronçon tu 
ne sais dans quel sens est le sens unique, on a avoir des accidents ;-(.
non. Quand il y a besoin de mettre un oneway=yes il FAUT (MUST) le 
mettre sur la portion qui va bien. Aucun ligne d'infrastructure 
ferroviaire (au sens rails, aiguillage, etc...) ne peut avoir d'autre 
opérateur[propriétaire que SNCF Réseau (sur le RFN puisque qu'il y a 
des rails propriété d'associations, d'industriels, etc. d'où l'intérêt 
de la super-relation RFN ;-).

La différence c'est qu'Il faut (SHOULD) factoriser tout ce qui peut l'être
Pour quoi faire ? On peut factoriser l'ensemble des "rue de la Mairie" 
pour ne mettre plus de noms sur les tronçons et les associatedStreet. 
Mais ça n'a aucun sens.
C'est valable pour l'ensemble des attribut=valeur. Pourquoi pas une 
relation des routes à 90 km/h ?
Les éditeurs signalent quand des relations ne sont que partiellement 
chargées.
Imagine que l'on télécharge des relations complètes. Et hop, voici tout 
le RFN chargé alors que l'utilisateur voulait juste modifier un jardin 
le long de la voie.


Tu ne veux pas mettre oneway=yes au niveau de la relation et 
oneway=no sur les tronçons bidirectionnels ?

non
C'est à l'éditeur de proposer un oneway=yes, le contributeur, soit il 
le sait, soit il ne le sait pas. S'il le sait, autant qu'il l'entre. 
S'il ne le sait pas, il vaut mieux que l'éditeur ne fasse pas 
d'hypothèse. Bon tu me diras qu'on n'est pas trop à la créations de 
voies ferrées en France (sauf LGV) et plutôt à arrêter les lignes 
bidirectionnelles.
j'arrive de plus en plus à distinguer l'éditeur utilisé (JOSM ou pas) 
simplement au fait que certaines valeurs sont remplies ou pas. Suivant 
cette logique, les mêmes réalités sont potentiellement représentées 
par un ensemble de tags différents suivant l'éditeur utilisé. Des fois 
c'est bien quand ce sont des éditeurs spécialisés (Mapcontrib), des 
fois pas.

On est d'accord : il vaut mieux s'entendre sur les valeurs à mettre.
Par exemple je vois que sur la ligne Carhaix-Guingamp tu as remonté 
l'info ref et gauge notamment au niveau de cette relation. Ça a du sens 
(c'est plus pratique pour le train que la gauge soit constante) et cette 
relation a un sens.
Il y a des valeurs par défaut décrites dans le wiki (à défaut dans 
le sens commun des contributeurs/_utilisateurs) ; il revient aux 
exportateurs de transcrire ces valeurs par défaut dans des produits 
"standardisés".
Quand tu te trouves du côté de Xouaxange 
, c'est 
bien pratique de savoir si le train roule à gauche (comme en France 
car Napoléon ne croyait pas au développement du train) ou à droite 
(comme en Allemagne car la voie a pris de l'ampleur quand 
l'Alsace-Moselle était en Allemagne).
Je crois que Jérôme te fera un topo sur l'intérêt de ne pas reposer 
sur des valeurs par défaut.


Pas besoin : je travaille chez SNCF Réseau à Strasbourg : je crois 
connaitre le sujet assez bien quoique toujours preneur d'autres regards.
Toi non, le "tu" était générique : l'utilisateur d'OSM.Qui lui ne sait 
pas forcément.


Un intérêt d'avoir les sens de circulations usuels (même si 
l'utilisateur lambda ne conduit pas de train) c'est aussi que les 
logiciels style Mapillary suggèrent les oneway manquants. Sur une voie 
exprès ou une autoroute on a oneway=yes, ça ne veut pas dire qu'en cas 
de travaux on ne roulera pas sur une voie de l'autre côté, à contresens 
selon OSM. Mais dans le bon sens selon openDataBase ;-).


Le 2016-06-04 à 21:31, Jérôme Seigneuret - 

[OSRM-talk] Eliminating, or reconstructing, via points

[Richard Fairhurst]

Two similar via-points-related questions I'd like to hear people's 
opinions on. I realise that out-of-the-box OSRM might not be able to 
solve these efficiently, but I'd be interested to hear ideas how one 
might build a plugin (or other code) to solve these.



1. Sometimes users of cycle.travel plan routes with a _lot_ of via 
points, e.g. http://cycle.travel/map/journey/19429 . Often, many of 
these via points are unnecessary: for example, the route from 'via 13' 
to 'via 15' would pass through 'via 14' anyway.


I'd like to add an option to eliminate these unnecessary points. I could 
do a fairly naive implementation, repeatedly routing between each pair 
and eliminating those which aren't necessary, but wonder if there's a 
smarter way of doing it.



2. Often people ask for a way to upload routes (e.g. in GPX or KML 
format, perhaps created with another routing website). This would be 
cool if the resulting routes were editable.


In other words, for a given polyline, reconstruct the via points 
necessary for (an approximation of) that polyline.


Strava built something like this the other year: 
https://twitter.com/paulmach/status/668921393656954880 . I can't get it 
to work, but the "divide and conquer" principle I guess is basically 
analogous to Douglas-Peucker: find a route from (start) to (end), find 
the polyline point furthest from the generated route, add a via there, 
and repeat until no points are more than n metres from the route.


Again, I could probably hack a naive implementation together, but wonder 
if there's a smarter way to do it!



Any ideas welcome. These could be fun challenges but I'd just like to 
get some second opinions before embarking on them...


cheers
Richard

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

Re: [OSM-talk-fr] ERDF (et RFF) ont changé de nom

[Jérôme Seigneuret]

> SNCF Réseau est gestionnaire de l'infrastructure et, à ce titre, détient
> le monopole. Ce monopole n'est pas prêt d'être partagé puisque la seule
> chose à partager c'est la dette.
>

>
Le débat est lié au terme utilisé pour *operator *sur les linéaires ou les
relations.
Le monopole n'est que temporaire (à mon avis si l'Europe continue) et n'est
valable que sur le réseau national et non sur les réseau locaux existants
(il y a toujours des exceptions) mais bon quand on a un gars sur le terrain
pour suivre des prestataires, on peut se demander si l'intérêt de celui-ci
quand la maintenance est sous-traité. Les gens du terrain parlent toujours
trop... (Mais bon, l'Alsace c'est un autre monde en France. ;-) )

Dans l'électricité il n'y a pas vraiment de monopole mais un système de
concession comme pour les autoroutes et l'aériens.

Quand à la dette il y a une différence entre être possesseur du réseau et
en faire la maintenance. Il y a encore peut c'est RFF qui possédait cette
dette (la SNCF avant ça) et SNCF Infra qui en avait la gestion (pourtant la
dette c'est pas l'infra qui la supportée)  Bref c'est juste un jeu
d'écriture pour cette histoire de fusion comme ça l'a été à la création de
RFF. On a pas fini de voir la fin du tunnel sur l'ouverture à la
concurrence imposé par l'Europe. >>> AUTRE DEBAT POUR UN AUTRE SUJET ;-)

Un réseau implique usuellement une topologie, là c'est juste "est opéré
> par".
>
Oui mais le niveau de topologie dépend de la précision des données saisies
et de l'homogénéité que l'on peut apporté. Il y a qu'à voir le système
routier avec les schémas coexistants ou la gestions des carrefours
complexes, les relations pour éviter de pouvoir faire des demi-tours sur
les voies de sortie/entrée de rond-points Quelle est la part qui est à
imputer au soft et celle à gérer dans la base?

> Est-ce une bonne pratique de mettre systématiquement oneway=no sur toute
> la voirie standard ?
>
> Non je pense que quand on a 90% des cas où c'est une valeur implicite. Il
faut préciser les autres cas (méconnaissance, ou oui, ou cas particulier
dans des conditions de service) ( Le wiki doit préciser ces cas et servir
de notice pour que les applications soient en capacité d'exploiter les
données. C'est le cas des routes. Là où je suis d'accord, c'est quand on a
trop d'effets de bord ou de cas possible différents et des cas qui implique
trop de requête pour exploiter correctement cette information.

oneway=no ce n'est pas pour moi l'un des cas les plus visible surtout que
c'est plutôt dans ce cas du oneway=reversible. Il y a des gares où le chef
de gare doit appeler la gare suivante pour que le train puisse partir. La
signalisation est dans les deux sens. Dans tous les cas où la signalisation
est unidirectionnel on aura un oneway=yes (est peut-être
oneway:conditionnal=no @ {condition à définir} )
A savoir que dans la plupart des cas, on dispose que de la ligne dans osm
et non les voies. Donc difficile de mettre les bons termes.

> oui, car il a des tronçons à voie unique. De plus si par tronçon tu ne
> sais dans quel sens est le sens unique, on a avoir des accidents ;-(.
>

Non car la carto n'est pas une donnée à suivre dans les système
opérationnels. Quand j'étais à Réseau on avait un SI lignes et non voies et
je suis pas sûr qu'actuellement un SI voies soit opérationnel.


> Tu ne veux pas mettre oneway=yes au niveau de la relation et oneway=no sur
> les tronçons bidirectionnels ?
> C'est à l'éditeur de proposer un oneway=yes, le contributeur, soit il le
> sait, soit il ne le sait pas. S'il le sait, autant qu'il l'entre. S'il ne
> le sait pas, il vaut mieux que l'éditeur ne fasse pas d'hypothèse.
>

C'est bien pour cela qu'au niveau aérien il n'y a rien et que le wiki se
dégage de responsabité et dit clairement que c'est pas pour un usage
opérationnel  ;-) C'est pas sûr comme système et heureusement c'est pas
n'importe qui qui roule avec un train et c'est pas toi qui choisi
l'aiguillage :-) le système ferroviaire n'utilise pas un SIG pour choisir
l'aiguillage.
Tu veux un GPS ferroviaire XD non je déconne.


> Bon tu me diras qu'on n'est pas trop à la créations de voies ferrées en
> France (sauf LGV) et plutôt à arrêter les lignes bidirectionnelles.
>

Arrêter oui et non. Ne plus en créer ok. Les fermer sûrement. Réduire les
systèmes d'aiguillages complexe carrément! Vu qu'avec la mise en service
des systèmes de contrôle d’aiguillage électronique on a simplifié et perdu
des connaissances dans ce domaines avec le temps, on sait pas faire donc on
simplifie.

La bidirectionnalité n'est pas seulement lié à l'usage par défaut mais à
l’existence des systèmes physiques permettant de gérer la signalisation.
Dans le cas de maintenance sur les voies il y a des cas où le train peut
rouler sur la voie de gauche comme à droite. Dans le cas ou la ligne
possède plus de 2 voies ça se complique encore. Celle du centre peut servir
pour le sens gauche ou droite. La voie de droite ou de gauche peut être une
voie réservé 

Re: [OSM-talk-fr] ERDF (et RFF) ont changé de nom

[DH]

Le 04/06/2016 19:43, osm.sanspourr...@spamgourmet.com a écrit :

le 2016-06-04 à 19:18, DH - dhel...@free.fr a écrit :

Le RFN n'est pas un réseau de voies ferrés donc ? what else ?
Un réseau implique usuellement une topologie, là c'est juste "est 
opéré par". 
Ah bon ? Selon toi, les trains soit, sortent du RFN le temps de trouver 
le prochain tronçon, soit demande la permission à un autre opérateur 
(lequel ?) pour retraper le RFN ?
Je te rassures, il n'en est rien, le RFN EST topologique. Et il n'est 
pas "juste" opéré par ; juridiquement SNCF Réseau en est aussi le 
propriétaire (avec tous les emmerdements qui vont avec)
Est-ce une bonne pratique de mettre systématiquement oneway=no sur 
toute la voirie standard ?
oui, car il a des tronçons à voie unique. De plus si par tronçon tu ne 
sais dans quel sens est le sens unique, on a avoir des accidents ;-(.
non. Quand il y a besoin de mettre un oneway=yes il FAUT (MUST) le 
mettre sur la portion qui va bien. Aucun ligne d'infrastructure 
ferroviaire (au sens rails, aiguillage, etc...) ne peut avoir d'autre 
opérateur[propriétaire que SNCF Réseau (sur le RFN puisque qu'il y a des 
rails propriété d'associations, d'industriels, etc. d'où l'intérêt de la 
super-relation RFN ;-).

La différence c'est qu'Il faut (SHOULD) factoriser tout ce qui peut l'être
Tu ne veux pas mettre oneway=yes au niveau de la relation et oneway=no 
sur les tronçons bidirectionnels ?

non
C'est à l'éditeur de proposer un oneway=yes, le contributeur, soit il 
le sait, soit il ne le sait pas. S'il le sait, autant qu'il l'entre. 
S'il ne le sait pas, il vaut mieux que l'éditeur ne fasse pas 
d'hypothèse. Bon tu me diras qu'on n'est pas trop à la créations de 
voies ferrées en France (sauf LGV) et plutôt à arrêter les lignes 
bidirectionnelles.
j'arrive de plus en plus à distinguer l'éditeur utilisé (JOSM ou pas) 
simplement au fait que certaines valeurs sont remplies ou pas. Suivant 
cette logique, les mêmes réalités sont potentiellement représentées par 
un ensemble de tags différents suivant l'éditeur utilisé. Des fois c'est 
bien quand ce sont des éditeurs spécialisés (Mapcontrib), des fois pas.


Il y a des valeurs par défaut décrites dans le wiki (à défaut dans le 
sens commun des contributeurs/_utilisateurs) ; il revient aux 
exportateurs de transcrire ces valeurs par défaut dans des produits 
"standardisés".
Quand tu te trouves du côté de Xouaxange 
, c'est 
bien pratique de savoir si le train roule à gauche (comme en France 
car Napoléon ne croyait pas au développement du train) ou à droite 
(comme en Allemagne car la voie a pris de l'ampleur quand 
l'Alsace-Moselle était en Allemagne).
Je crois que Jérôme te fera un topo sur l'intérêt de ne pas reposer 
sur des valeurs par défaut.


Pas besoin : je travaille chez SNCF Réseau à Strasbourg : je crois 
connaitre le sujet assez bien quoique toujours preneur d'autres regards.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] MAPS.ME maggior diffusione OSM inizio nuovi problemi... Seri!

[Federico Cortese]

2016-06-04 20:06 GMT+02:00 Alecs :
> qualcuno l'ha provata?
>

Io l'ho installata stamattina per curiosità.
Il rendering è molto accattivante, con visualizzazione 3D dove è
inserito il building:levels o l'altezza dei fabbricati.
Non ho capito a prima vista a che data sono aggiornate le mappe, ma
penso a cadenza mensile tipo Osmand.
Vedrò di fare qualche prova di upload in OSM, in caso vi faccio sapere.

Ciao
Federico

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

Re: [Talk-GB] UK address tagging

[Colin Smale]

Chris, local authorities only deal with house number and street naming. The 
rest is down to Royal Mail. Should we perhaps start by asking ourselves what we 
mean by an address in the context of OSM? Is it actually a postal address? That 
is certainly what I think most people would expect.

//colin

On 4 June 2016 19:54:15 CEST, Chris Hill  wrote:
>We certainly don't need the phoney, contrived postal town. That is
>purely a Royal Mail invention that serves no useful purpose for anyone
>else. RM is just one user of addressing amongst many.
>
>Addressing is not created by Royal Mail, it is maintained by local
>authorities. We should start there.
>
>Cheers, Chris (chillly)
>
>On 4 June 2016 16:50:37 BST, Colin Smale  wrote:
>>Hi, 
>>
>>I am wondering if there is any consensus about tagging for addresses
>in
>>the UK. I couldn't find any trace of a discussion, nor anything on the
>>wiki, but I may have missed something. In particular I am wondering
>>about locality vs. post town - one of these should probably go in
>>addr:city, but which one, and how do we tag the other one? 
>>
>>The address model used by Royal Mail is rather complex when compared
>to
>>some of the straightforward systems in mainland European countries,
>>which mostly manage with {number,street,postcode,town}. In the UK we
>>need something like
>>{[buildingname,](number|name),street,[dependent-street,][locality,]post-town,postcode}
>>for a full address (actually it appears even more complex than that,
>if
>>you refer to [1]). 
>>
>>Is anyone aware of a reference for how to map address fields to OSM
>>tags? 
>>
>>--colin 
>>
>>[1]
>>http://www.upu.int/fileadmin/documentsFiles/activities/addressingUnit/gbrEn.pdf
>>
>>
>>
>>___
>>Talk-GB mailing list
>>Talk-GB@openstreetmap.org
>>https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-it] MAPS.ME maggior diffusione OSM inizio nuovi problemi... Seri!

[Alecs]

Penso anche io che questi casi "problematici" sono di turisti (tra le città
colpite dai "nomi cinesi", oltre a Milano, ho visto Roma, Firenze, Venezia,
Pisa, Atene, Barcellona, Parigi) che molto probabilmente non hanno
familiarità con OSM. Almeno ora abbiamo qualche name:zh in più che non dà
fastidio anzi, gli ultimi due li ho cancellati perchè, se prendo per buono i
risultati che mi dà google senza sapere il cinese, uno è un quadro che si
trova nella pinacoteca di Brera, l'altro la Galleria Vittorio Emanuele e non
il monumento, erano anche sbagliati insomma.
Il problema dal lato app mi sembra, tra gli altri, che non "conosce" molti
tag relativamente comuni, tra cui le declinazioni di name:xx in varie
lingue, non avendola mai usata però non so dire dove sia il problema,
qualcuno l'ha provata?



--
View this message in context: 
http://gis.19327.n5.nabble.com/MAPS-ME-maggior-diffusione-OSM-inizio-nuovi-problemi-Seri-tp5874719p5874768.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-de] EnBW erneuert Ladesäulen für Elektroautos

[Joachim Kast]

> 
> 
>> Schaut bei Gelegenheit in eurer Nähe ob die Daten noch aktuell sind.
> 
> Ich möchte mal Verallgemeinern:
> Hier : http://osm.org/go/0JFSCY89B?m=
> ist eine Elektroladesäule vorhanden, wird aber nicht gerendert.
> Hat das einen Grund?
> 

OpenStreetMap ist eine Geodatenbank. Die verschiedenen Kartenersteller
entscheiden, was sie darstellen und was nicht. Die Ladestationen werden
auf der Hauptkarte nicht angezeigt, aber z.B bei OsmAnd und sind dort
auch als POI suchbar.

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

Re: [Talk-GB] UK address tagging

[Chris Hill]

We certainly don't need the phoney, contrived postal town. That is purely a 
Royal Mail invention that serves no useful purpose for anyone else. RM is just 
one user of addressing amongst many.

Addressing is not created by Royal Mail, it is maintained by local authorities. 
We should start there.

Cheers, Chris (chillly)

On 4 June 2016 16:50:37 BST, Colin Smale  wrote:
>Hi, 
>
>I am wondering if there is any consensus about tagging for addresses in
>the UK. I couldn't find any trace of a discussion, nor anything on the
>wiki, but I may have missed something. In particular I am wondering
>about locality vs. post town - one of these should probably go in
>addr:city, but which one, and how do we tag the other one? 
>
>The address model used by Royal Mail is rather complex when compared to
>some of the straightforward systems in mainland European countries,
>which mostly manage with {number,street,postcode,town}. In the UK we
>need something like
>{[buildingname,](number|name),street,[dependent-street,][locality,]post-town,postcode}
>for a full address (actually it appears even more complex than that, if
>you refer to [1]). 
>
>Is anyone aware of a reference for how to map address fields to OSM
>tags? 
>
>--colin 
>
>[1]
>http://www.upu.int/fileadmin/documentsFiles/activities/addressingUnit/gbrEn.pdf
>
>
>
>___
>Talk-GB mailing list
>Talk-GB@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] ERDF (et RFF) ont changé de nom

[osm . sanspourriel]

le 2016-06-04 à 19:18, DH - dhel...@free.fr a écrit :

Le RFN n'est pas un réseau de voies ferrés donc ? what else ?
Un réseau implique usuellement une topologie, là c'est juste "est opéré 
par".
Est-ce une bonne pratique de mettre systématiquement oneway=no sur 
toute la voirie standard ?
oui, car il a des tronçons à voie unique. De plus si par tronçon tu ne 
sais dans quel sens est le sens unique, on a avoir des accidents ;-(.
Tu ne veux pas mettre oneway=yes au niveau de la relation et oneway=no 
sur les tronçons bidirectionnels ?
C'est à l'éditeur de proposer un oneway=yes, le contributeur, soit il le 
sait, soit il ne le sait pas. S'il le sait, autant qu'il l'entre. S'il 
ne le sait pas, il vaut mieux que l'éditeur ne fasse pas d'hypothèse. 
Bon tu me diras qu'on n'est pas trop à la créations de voies ferrées en 
France (sauf LGV) et plutôt à arrêter les lignes bidirectionnelles.


Il y a des valeurs par défaut décrites dans le wiki (à défaut dans le 
sens commun des contributeurs/_utilisateurs) ; il revient aux 
exportateurs de transcrire ces valeurs par défaut dans des produits 
"standardisés".
Quand tu te trouves du côté de Xouaxange 
, c'est 
bien pratique de savoir si le train roule à gauche (comme en France car 
Napoléon ne croyait pas au développement du train) ou à droite (comme en 
Allemagne car la voie a pris de l'ampleur quand l'Alsace-Moselle était 
en Allemagne).
Je crois que Jérôme te fera un topo sur l'intérêt de ne pas reposer sur 
des valeurs par défaut.


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

Re: [Talk-it] MAPS.ME maggior diffusione OSM inizio nuovi problemi... Seri!

[Andrea Lattmann]

Ho detto una fesseria. Si riesce a ricercare tramite bundle_id? Se si è 
com.mapswithme.maps.pro
Comunque la tua query è giusta allora... 
Scusami

Andrea Lattmann

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

Re: [Talk-it] MAPS.ME maggior diffusione OSM inizio nuovi problemi... Seri!

[Andrea Lattmann]

>- avevamo già visto in passato un >problema simile con quella app che 
>>piazzava note sui limiti di velocità >(Wisepilot), ma questa va ben oltre

Ora che aprono note insieme a maps.me c'è pure navmii, ma almeno quello non 
permette modifiche. Quindi in giro per l' Italia ci sono note navmii e maps.me.

Andrea Lattmann

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

Re: [Talk-it] MAPS.ME maggior diffusione OSM inizio nuovi problemi... Seri!

[Andrea Lattmann]

>non capisco perchè overpass trova >created_By=JOSM... e non MAPS...

Scusami, non sono un esperto di overpass, ma credo che sia sbagliata la query 
perché non c'è MAP. Ora Alecs01 ha sistemato e non riesco a dirti l' ID, perché 
sono fuori casa. A memoria era com.mymapsmepro. poi non ricordo...

Andrea Lattmann

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

Re: [OSM-talk-fr] ERDF (et RFF) ont changé de nom

[DH]

Le 04/06/2016 16:24, Jérôme Seigneuret a écrit :



Le 03/06/2016 à 23:26, DH a écrit :

Justement l'idée c'est d'avoir, à terme, une super relation
"Réseau Ferré National" avec operator=SNCF Réseau (1), dedans
toutes les relations de lignes composées des relations de
voies, composées des tronçons, les relations de gares

Bœurk… Je suis le seul à trouver ça affreux ?
JB.

Non je suis aussi contre ce genre de pratique. Qu'il y ai une
super relation sur l'usage des voies commerciale peut se
comprendre mais c'est pas réservé au fait que l’opérateur soit
SNCF Réseau. En plus rien n'est dit que dans le temps (avec
l'ouverture à la conccurance) SNCF Réseau soit l'opérateur qui en
sera en charge... Mais bon ça c'est un autre débat.



Personne n'a, pour le moment, parlé de voies commerciales. SNCF Réseau 
est gestionnaire de l'infrastructure et, à ce titre, détient le 
monopole. Ce monopole n'est pas prêt d'être partagé puisque la seule 
chose à partager c'est la dette.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] MAPS.ME maggior diffusione OSM inizio nuovi problemi... Seri!

[Andrea Lattmann]

>Così come per quel nodo vicino >all'aeroporto di Orio alSerio non è male
>avere il nome in russo (name:ru)

Concordo, sono informazioni utili. C'è anche un utente MAPS.ME che ha tentato 
più volte di cancellare un agenzia viaggi e non ci è riuscito (perché per 
fortuna MAPS.ME non lo permette per adesso, ma credo che il "pulsante" cancella 
sia già stato predisposto).

Andrea Lattmann

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

Re: [OSM-talk-fr] ERDF (et RFF) ont changé de nom

[DH]

Le 04/06/2016 11:17, Éric Gillet a écrit :
Le 4 juin 2016 à 05:48, JB > a écrit :


Le 03/06/2016 à 23:26, DH a écrit :

Justement l'idée c'est d'avoir, à terme, une super relation
"Réseau Ferré National" avec operator=SNCF Réseau (1), dedans
toutes les relations de lignes composées des relations de
voies, composées des tronçons, les relations de gares 


Bœurk… Je suis le seul à trouver ça affreux ?

Je suis aussi de cet avis. Les relations ne sont pas des catégories 
. 
Chaque élément (tronçons, gares, etc.) sont gérés individuellement et 
donc méritent un tag operator=*, un gauge=*, etc.
L'usage de relation permet de lier plusieurs éléments entre eux, comme 
un réseau de voie ferrées, un itinéraire ou autre.


Le RFN n'est pas un réseau de voies ferrés donc ? what else ?
Est-ce une bonne pratique de mettre systématiquement oneway=no sur toute 
la voirie standard ?
Il y a des valeurs par défaut décrites dans le wiki (à défaut dans le 
sens commun des contributeurs/_utilisateurs) ; il revient aux 
exportateurs de transcrire ces valeurs par défaut dans des produits 
"standardisés".
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Best practices for dealing with old TIGER tags?

[Paul Johnson]

On Sat, Jun 4, 2016 at 10:29 AM, Eric Ladner  wrote:

> On Sat, Jun 4, 2016 at 5:58 AM Greg Troxel  wrote:
>
>>
>> Kevin Kenny  writes:
>>
>> > OK, 'residential' if it looks like 'subdivision', 'unclassified'
>> > otherwise (as long as it's drivable in, say, my daughter's car rather
>> > than my 4-wheeler). Got it.
>>
>> I also see a distinction between residential/unclassified as denoting a
>> legal road (around me, carved-out parcel wise from the surrounding land)
>> vs track and some service denoting a non-legal-road.  However, others
>> see the physical and legal attributes as separate.
>>
>>
> My understanding of the description of "unclassified" is unclassified is a
> step between residential and tertiary.   It's a connecting road, minor
> connector, whatever, that doesn't have residential on it, but it's not high
> enough in classification to make it a tertiary road.
>

Generally speaking, yes.  It's roughly the BFE version of residential.


> I usually use it for roads in industrial complexes, loops around malls,
> business complexes, or other connectors/roads where there's no obvious
> residential around.
>

That might work in some situations but for the most part, that's
highway=service; service=*
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Best practices for dealing with old TIGER tags?

[Greg Troxel]

Eric Ladner  writes:

> On Sat, Jun 4, 2016 at 5:58 AM Greg Troxel  wrote:
>
>>
>> Kevin Kenny  writes:
>>
>> > OK, 'residential' if it looks like 'subdivision', 'unclassified'
>> > otherwise (as long as it's drivable in, say, my daughter's car rather
>> > than my 4-wheeler). Got it.
>>
>> I also see a distinction between residential/unclassified as denoting a
>> legal road (around me, carved-out parcel wise from the surrounding land)
>> vs track and some service denoting a non-legal-road.  However, others
>> see the physical and legal attributes as separate.
>>
> My understanding of the description of "unclassified" is unclassified is a
> step between residential and tertiary.   It's a connecting road, minor
> connector, whatever, that doesn't have residential on it, but it's not high
> enough in classification to make it a tertiary road.

I agree with that notion.

> I usually use it for roads in industrial complexes, loops around malls,
> business complexes, or other connectors/roads where there's no obvious
> residential around.

Mostly agree, but I only use it for legal roads, not driveways or
private roads.  Meaning someplace where (in new england) it's legally
separate and the public has a right of access.


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

[OSM-talk-nl] Hangout Openbaar Vervoer

[Jo]

Hallo,

Vanavond om 20u leg ik iemand in Nederland uit hoe Openbaar Vervoer te
taggen. Eigenlijk om te taggen, want er zijn wat wijizigingen in Amsterdam.

Daarbij toon ik dan waar Darya in het kader van GSoC mee bezig is. Al is
dat nog in een heel pril stadium.

https://hangouts.google.com/hangouts/_/mbss2ayitrc7vnijf2g4bvgynue

Hi,

Tonight at 20h CEST I'll explain a bit about how to tag public transport.
There are some modifiations around the bus station of Amsterdam, which
involve retagging many bus routes.

I'll also show a bit what Darya is doing for GSoC, but that is still in
very early stages.

https://hangouts.google.com/hangouts/_/mbss2ayitrc7vnijf2g4bvgynue

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

[OSM-talk-be] Hangout Openbaar Vervoer

[Jo]

Hallo,

Vanavond om 20u leg ik iemand in Nederland uit hoe Openbaar Vervoer te
taggen. Eigenlijk om te taggen, want er zijn wat wijizigingen in Amsterdam.

Daarbij toon ik dan waar Darya in het kader van GSoC mee bezig is. Al is
dat nog in een heel pril stadium.

https://hangouts.google.com/hangouts/_/mbss2ayitrc7vnijf2g4bvgynue

Hi,

Tonight at 20h CEST I'll explain a bit about how to tag public transport.
There are some modifiations around the bus station of Amsterdam, which
involve retagging many bus routes.

I'll also show a bit what Darya is doing for GSoC, but that is still in
very early stages.

https://hangouts.google.com/hangouts/_/mbss2ayitrc7vnijf2g4bvgynue

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

Re: [Talk-us] Best practices for dealing with old TIGER tags?

[Eric Ladner]

On Sat, Jun 4, 2016 at 5:58 AM Greg Troxel  wrote:

>
> Kevin Kenny  writes:
>
> > OK, 'residential' if it looks like 'subdivision', 'unclassified'
> > otherwise (as long as it's drivable in, say, my daughter's car rather
> > than my 4-wheeler). Got it.
>
> I also see a distinction between residential/unclassified as denoting a
> legal road (around me, carved-out parcel wise from the surrounding land)
> vs track and some service denoting a non-legal-road.  However, others
> see the physical and legal attributes as separate.
>
>
My understanding of the description of "unclassified" is unclassified is a
step between residential and tertiary.   It's a connecting road, minor
connector, whatever, that doesn't have residential on it, but it's not high
enough in classification to make it a tertiary road.

I usually use it for roads in industrial complexes, loops around malls,
business complexes, or other connectors/roads where there's no obvious
residential around.

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

Re: [Talk-us] How to get open street maps

[ajt1...@gmail.com]

On 28/05/2016 11:51, David Niklas wrote:

Hello,
I downloaded the maps, but they changed over night, so the md5 sums don't
match up. I tried using rsync -cav to ftp.spline.de, but the connection
times out "[Receiver] io timeout after 181 seconds -- exiting" (return
code 30) I know that the port is accessible because I used nmap on it. I
tried passing the --timeout flags but that made no difference. What could
I do? I can't download that much data from scratch and a subset of the
world cannot be resynced with the master?


What to download depends very much on what you want to do.  It sounds 
like you're trying to download the whole planet from a mirror of 
http://planet.osm.org/ (see also 
http://wiki.openstreetmap.org/wiki/Planet.osm ).


If you want OSM data for a small country or region, then I'd start with 
one of the extracts mentioned at those links. 
http://download.geofabrik.de/ is a good start because you can see what 
you're getting and how big it's going to be.


If you really do want OSM data for the whole planet then have a look at 
http://planet.osm.org/planet/2016/ for how often they change - that 
should enable you to time the download of a whole one before it gets 
replaced with a new version (or go for a particular date rather than 
"latest").  It's 50Gb though, so as well as taking a while to download 
it'll take a while to do anything useful with once you have downloaded it.


However if you really do want "maps" rather than "data", then where to 
go depends on what you want maps for.  For example, various maps that 
are suitable for a Garmin handheld or satnav are available (such as 
http://garmin.openstreetmap.nl/ , see 
http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Download ), but 
they won't work with (say) MAPS.ME or OsmAnd on a phone.


If you instead want all the examples of a particular tag* in OSM, then 
you can start with something like 
http://taginfo.openstreetmap.org/tags/railway=station and click through 
to see that on a map by clicking the "Overpass Turbo" link there (and 
get that data as JSON by clicking the "data" link at the top right).


The best place for general "How do I do X" questions is probably the 
help site https://help.openstreetmap.org/ .


Best Regards,

Andy

* and see http://wiki.openstreetmap.org/wiki/Elements for more info 
about that.



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

Re: [Talk-it] MAPS.ME maggior diffusione OSM inizio nuovi problemi... Seri!

[Max1234Ita]

+1

Così come per quel nodo vicino all'aeroporto di Orio alSerio non è male
avere il nome in russo (name:ru)

:-)


In ogni caso, credo che dovrebbe essere OSM stessa a muoversi nei confronti
degli sviluppatori di queste app, quantomeno chiedendo di dare maggiori
informazioni all'utente prima di abilitarlo alle modifiche: dopotutto è
anche nel loro stesso interesse avere i migliori database possibili:

Purtroppo molti utenti (soprattutto quelli "casual") sono tratti in inganno,
per così dire, dal fatto che l'app da loro usate presenta le cose in modo
"bello & facile"; peccato che non sempre (anzi quasi mai) le cose siano,
"under the hood" così belle e facili come presentate.

Max



--
View this message in context: 
http://gis.19327.n5.nabble.com/MAPS-ME-maggior-diffusione-OSM-inizio-nuovi-problemi-Seri-tp5874719p5874750.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [OSM-talk-nl] Verplaatsen bushaltes/routes Amstelstation

[Marc Zoutendijk]

> Op 4 jun. 2016, om 14:10 heeft Freek Dijkstra  het 
> volgende geschreven:
> 
> Het busstation bij Amsterdam Amstel is verplaatst, en zal later nogmaals
> verplaatst worden (zie https://www.amsterdam.nl/amstelstation 
> ).
> 
> Er lopen busroutes over dit terrein, en die wil ik graag ook
> verplaatsen. Wat is de beste manier om routes te bewerken? Ik gebruik
> eigenlijk alleen de online editor op osm.org , maar die 
> interface is niet
> helemaal geschikt.

Hoi Freek,

Lees vooral ook deze OV-discussies op het forum (dat trouwens aanmerkelijk 
vaker wordt bezocht/gelezen dan deze list):

http://forum.openstreetmap.org/viewtopic.php?id=53844 


http://forum.openstreetmap.org/viewtopic.php?id=54271 


http://forum.openstreetmap.org/viewtopic.php?id=27742 


http://forum.openstreetmap.org/viewtopic.php?id=34039 


Om te voorkomen dat je het werk dat anderen al hebben gedaan (of gepland hebben 
te gaan doen) weer gaat wijzigen of ongedaan maakt.
En ik zou zeker op het aanbod van Polyglot ingaan, want de iD editor die je 
waarschijnlijk gebruikt is voor deze zaken tamelijk ongeschikt.

Marc.

PS. Ik weet niet of je helemaal nieuw bent, zoja, kijk dan in de helpwiki voor 
nieuwe mappers:
http://wiki.openstreetmap.org/wiki/Welkom_op_OSM 



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

Re: [Talk-cu] comunidad OSM en Cuba!

[Hédel Nuñez Bolívar]

jeje, gracias por el correo Guillermo. Mis blogs son http://blog.hedmon.com/
y http://www.checolatin.com/ pero no tienen que ver mucho con el tema,
quizás un poco el primero que lo uso más para cosas 'técnicas'. Por eso
creo que podamos crear un blog específico para el grupo, si es que se van a
generar contentidos. Los miembros pudieran inscribirse para recibir
newsletters y así pudieran recibir los posts en el correo, que creen?

Regards,

*Ing. Hédel Nuñez Bolívar*
http://www.hedmon.com
he...@hedmon.com


2016-06-03 14:35 GMT+02:00 Guillermo López :

> Hola Hedel.
> Gracias por el apoyo. En algun momento podriamos necesitar alguna
> ayuda "del exterior". jaja. No, serio. Comparte el enlace para tus
> blogs y sigue editando siempre que puedas.
>
> Un saludo
>
> El 2/6/16, Hédel Nuñez Bolívar  escribió:
> > Hola a todos,
> > Me alegra mucho ver que la comunidad en Cuba se impulsa. Lamentablemente
> > vivo en el exterior y me resulta imposible participar en los mapatones
> de la
> > isla, aunque desde la distancia una de las vías que exploto para no
> sentirme
> > lejos es editar en OSM, sobre todo Habana del Este.
> > Tengo un par de blogs, en los cuales la verdad, no escribo mucho, pero
> si la
> > comunidad se compromete a generar contenidos, yo me comprometo a crear y
> > gestionar uno si es necesario.
> >
> > Si en algo más puedo ayudar me dicen.
> >
> > Sds
> >
> > Hédel
> >
> >> On 01 Jun 2016, at 17:02, Laura Barroso  wrote:
> >>
> >> Hola gente, ayer en la noche Pb y yo nos reunimos, el objetivo de la
> >> reunión: cómo organizar la comunidad osm en Cuba, y crear mecanismos
> para
> >> hacer mapatones en la ciudad.
> >>
> >> El asunto fundamental es que no tenemos mucha divulgación, la gente no
> >> sabe qué es OpenStreetMap. Algunas ideas que pensamos implementar:
> >>
> >> 1. Reunirnos una vez al mes como comunidad.
> >> 2. Buscar un espacio para mapear en papel(Alguien conoce algún dueño de
> un
> >> bar o algo parecido??)
> >> 3. Llegar a la gente de joven club(respecto a este punto ayer contacté
> con
> >> Rubén el antiguo jefe de movilidad de Desoft, para que nos facilitace el
> >> contacto con gente del palacio central)
> >> 4. Llegar a las secundarias y preuniversitarios(tal vez crear espacios
> >> para charlas?)
> >> 5. Hacer un video para el paquete para los mapatones(Ahora mismo el
> >> paquete constituye una fuente de distribución masiva a nivel nacional)
> >> 6. Contactar con blogueros que tengan que ver con tecnología(ya contamos
> >> con el apoyo de Jorge de cubava, su blog http://jorgen.cubava.cu/)
> >>
> >> La semana próxima nos reuniremos nuevamente para tratar el tema del
> guión
> >> para el video, divulgaré la cita por esta misma vía por si alguien
> quiere
> >> unirse...
> >> La discusión está abierta, si alguien tiene alguna idea o algo que
> aportar
> >> adelante!
> >>
> >>
> >>
> >>
> >>
> >> ___
> >> Talk-cu mailing list
> >> Talk-cu@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-cu
> >
> > ___
> > Talk-cu mailing list
> > Talk-cu@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cu
> >
>
> ___
> Talk-cu mailing list
> Talk-cu@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cu
>
___
Talk-cu mailing list
Talk-cu@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cu

Re: [OSM-talk-fr] ERDF (et RFF) ont changé de nom

[Jérôme Seigneuret]

Le 03/06/2016 à 23:26, DH a écrit :
>
>> Justement l'idée c'est d'avoir, à terme, une super relation "Réseau Ferré
>> National" avec operator=SNCF Réseau (1), dedans toutes les relations de
>> lignes composées des relations de voies, composées des tronçons, les
>> relations de gares
>>
> Bœurk… Je suis le seul à trouver ça affreux ?
> JB.
>
> Non je suis aussi contre ce genre de pratique. Qu'il y ai une super
> relation sur l'usage des voies commerciale peut se comprendre mais c'est
> pas réservé au fait que l’opérateur soit SNCF Réseau. En plus rien n'est
> dit que dans le temps (avec l'ouverture à la conccurance) SNCF Réseau soit
> l'opérateur qui en sera en charge... Mais bon ça c'est un autre débat.
>

Le route_master ne doit servir qu'a regrouper des portions d'itinéraire
plus petit ou de direction différentes (forward, backward et variante(s) si
elle(s) existe(nt))

En clair il regroupe des relations existantes et apporte un nom global sur
cet ensemble. C'est ce que l'on retrouve pour le véloroute, les bus et
autres itinéraires qui se composent d'itinéraires plus simples dont le
niveau de relation est inférieur.

Si l'on prend La Poste, il n'y a pas une super-relation pour regrouper
l'ensemble des boîtes que l'opérateur doit gérer. Là c'est le même principe
qui s'applique.


*En particulier dans l'exemple du réseau alsacien, je vois plein de
tronçons nommés "Ligne de Strasbourg-Ville à Saint-Dié".A minima je
m'attendrais à ce que là ce soit une relation qui porte ref="110 000"*

Oui et non. C'est pas un itinéraire mais une ligne. C'est bien un
regroupement de voies partant d'une gare à une autre. Donc elle a un nom
partant d'une gare A à B avec de potentielles gares intermédiaires)

Vu que l'itinéraire n'est pas le réseau mais l’exploite, l'opérateur dans
la relation sera SNCF Voyageurs, Fret SNCF, BD... et les informations
contenu par la relation pourront être différentes avec des variantes
(passage ou non par des gares intérmédiaires)
Les voies (et donc les lignes) sont gérées par l'épic SNCF Réseau. C'est
donc bien sur le linéaire qu'est l'information.

*Sinon pourquoi ne pas supprimer les noms des rues de la Mairie pour mettre
toutes les rues de la Mairie dans une relation "rue de la Mairie" ;-) ?*

On ne le fait pas car il n'y a pas de relation pour regrouper des voies
routières (sauf type=multipolygon) le cas de regroupement est basé sur
l'existance d'adresses postal et donc la création d'une relation
* associatedStreet*
Même pour les cours d'eau c'est pas possible. Car il y a un nom pour
l'affluent mais celui-ci peut changer de nom sur le tronçon en partant de
sa source vers son exutoire.

Pour le coté énergie électrique c'est assez simple aussi. On nous dit que
ERDF devient Enedis. La raison est simple: confusion avec EDF ...
Donc le gestionnaire du réseau que les plaques aient changé ou non est
Enedis. C'est un gestionnaire à 95% du parc Français. Il reste donc des
opérateurs différents ce qui est le cas sur certains barrages
hydrau-électriques comme la SHEM et la CNR (c'est aussi le cas des autres
énergies renouvelables)

EDF gère quoi? Ben rien à ce niveau car c'est la filiale Enedis qui se
charge du travail. Au même titre que c'est plus Engie (GDF) mais GRDF qui
s'occupe de la maintenance pour le gaz avec une obligation de neutralité.

EDF, Engie, SNCF sont des groupes dont la partie gestion et distribution a
été sortie pour des raisons de neutralité lors de l'ouverture à la
concurrence imposée par l'Europe. D'où les Epic Enedis, GRDF et SNCF Réseau

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

Re: [Talk-it] MAPS.ME maggior diffusione OSM inizio nuovi problemi... Seri!

[Federico Cortese]

Invece che cancellare il name in cinese si può aggiungere name:zh=.
Non è male avere anche il nome in cinese degli oggetti :-)))

Ciao
Federico

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

Re: [Talk-it] MAPS.ME maggior diffusione OSM inizio nuovi problemi... Seri!

[Andrea Albani]

Il giorno 4 giugno 2016 15:14, Cascafico Giovanni  ha
scritto:

> non capisco perchè overpass trova created_By=JOSM... e non MAPS...
>
> http://overpass-turbo.eu/s/gCP
>
>
Perchè ci sono dei nodi con il created_by creati prima che questo tag
divenisse deprecato per nodi, way e relazioni.
Ora il tag è consentito solo come metadato dei changeset.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] MAPS.ME maggior diffusione OSM inizio nuovi problemi... Seri!

[dgitto]

Perché in quel modo non cerchi nel metadato del changeset. Cerchi solo i tag sui nodi.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] MAPS.ME maggior diffusione OSM inizio nuovi problemi... Seri!

[Andrea Albani]

> Mi chiedo: Ma chi fa questo tipo di modifiche dovrà ben usare un account
> OSM... o no?
> Se è così, non varrebbe anche in questo caso la direttiva di correggere
> l'errore e lasciare un commento sul changeset? Già questo dovrebbe avere un
> certo effetto sui nuovi mappatori, che quasi certamente sono animati da
> buona volontà.
>
>
Ci sarà sicuramente una quota di utilizzatori di maps.me che vanno oltre,
ma penso che il 90% di questi "casual mappers"  siano più attirati dalle
potenzialità di un app di navigazione offline che dal resto.

Non metto in dubbio la loro buona fede, troveranno utile avere messo il
loro dato sulla mappa, ma poi torneranno a fare i turisti come Holly [0].
Me lo immagino così: Ieri 3 giugno era in Piazza Duomo a Milano, si è
registrato su OSM (perchè l'app lo richiede per fare le modifiche - non per
altro) e ha cambiato il nome al monumento di Vittorio Emanuele e poi alla
Pinacoteca di Brera. Forse voleva aggiungere il nome in cinese e forse
l'app gli consentiva solo di cambiare il tag name e non quello localizzato.

Agli utenti come lui possiamo giustamente lasciare un commento al
changeset, o convicere quelli di maps.me a sensibilizzare i propri utenti,
ma da soli mi sembrano strumenti poco efficaci per preservare la qualità
dei dati.


[0] https://www.openstreetmap.org/user/%E5%90%B4%E7%90%BCHolly
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-in] Rann of Kutch wetlands

[Johnson Chetty]

Quite a good read!

On 4 June 2016 at 18:42, Arun Ganesh  wrote:

> Some interesting discussion on mapping the mudflats of the Rann in the
> diary: http://www.openstreetmap.org/user/Alan/diary/38776
>
> --
> Arun Ganesh
> @planemad
> 
>
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-in
>
>


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

Re: [Talk-it] MAPS.ME maggior diffusione OSM inizio nuovi problemi... Seri!

[Cascafico Giovanni]

non capisco perchè overpass trova created_By=JOSM... e non MAPS...

http://overpass-turbo.eu/s/gCP

Il giorno 4 giugno 2016 15:08, Andrea Albani  ha scritto:

> Questa cosa la trovo preoccupante sotto diversi punti di vista:
> - avevamo già visto in passato un problema simile con quella app che
> piazzava note sui limiti di velocità (Wisepilot), ma questa va ben oltre
> - la funzionalità sembra attiva da poco tempo perchè l'annuncio è di
> inizio aprile [0], quindi mi aspetto un aggravamento della situazione
> - la app incriminata è stata scaricata dal solo Google Play almeno 40
> milioni di volte
> - non mi sembra ci sia un modo facile e diretto di individuare tutti i
> changeset incriminati. L'unica cosa che mi sembra li accomuni è il valore
> del metadato created_by che però non è ricercabile ne in Overpass ne
> tramite le API
> - nella lista internazionale ne ha parlato qualcuno in maggio [1], ma non
> sembra ci sia stata una grande discussione in merito.
>
> Secondo me lo sviluppatore dell'app dovrebbe implementare una qualche
> forma di controllo, perchè se i potenziali problemi dobbiamo inseguirli a
> posteriori non ne usciamo.
>
> Ciao
>
> [0] http://blog.maps.me/2016/04/lets-make-most-detailed-map-together.html
> [1] https://lists.openstreetmap.org/pipermail/talk/2016-May/075964.html
>
>
> Il giorno 4 giugno 2016 09:35, Andrea Lattmann 
> ha scritto:
>
>> Ciao ragazzi, come da oggetto, con le/la nuova versione di MAPS.ME da la
>> possibilità di effettuare modifiche ad OSM. Per ora non permette la
>> cancellazione (per fortuna). Questo ha introdotto un aumento di note sulla
>> mappa, molte volte criptiche, perché l' utente non lascia commenti, e
>> peggio ancora modifiche di questo genere [1].
>> Il name del Duomo di Milano è già stato modificato 3 volte ed il nostro
>> amico Alecs01 ha ripristinato il name. Come possiamo correre ai ripari?
>> Contattiamo tutti gli utenti MAPS.ME?? Rischiamo dei danni seri.
>> Grazie
>>
>> [1] https://www.openstreetmap.org/way/290222578
>>
>> Andrea Lattmann
>>
>> ___
>> 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-in] Rann of Kutch wetlands

[Arun Ganesh]

Some interesting discussion on mapping the mudflats of the Rann in the
diary: http://www.openstreetmap.org/user/Alan/diary/38776

-- 
Arun Ganesh
@planemad

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

Re: [Talk-it] MAPS.ME maggior diffusione OSM inizio nuovi problemi... Seri!

[Andrea Albani]

Questa cosa la trovo preoccupante sotto diversi punti di vista:
- avevamo già visto in passato un problema simile con quella app che
piazzava note sui limiti di velocità (Wisepilot), ma questa va ben oltre
- la funzionalità sembra attiva da poco tempo perchè l'annuncio è di inizio
aprile [0], quindi mi aspetto un aggravamento della situazione
- la app incriminata è stata scaricata dal solo Google Play almeno 40
milioni di volte
- non mi sembra ci sia un modo facile e diretto di individuare tutti i
changeset incriminati. L'unica cosa che mi sembra li accomuni è il valore
del metadato created_by che però non è ricercabile ne in Overpass ne
tramite le API
- nella lista internazionale ne ha parlato qualcuno in maggio [1], ma non
sembra ci sia stata una grande discussione in merito.

Secondo me lo sviluppatore dell'app dovrebbe implementare una qualche forma
di controllo, perchè se i potenziali problemi dobbiamo inseguirli a
posteriori non ne usciamo.

Ciao

[0] http://blog.maps.me/2016/04/lets-make-most-detailed-map-together.html
[1] https://lists.openstreetmap.org/pipermail/talk/2016-May/075964.html


Il giorno 4 giugno 2016 09:35, Andrea Lattmann 
ha scritto:

> Ciao ragazzi, come da oggetto, con le/la nuova versione di MAPS.ME da la
> possibilità di effettuare modifiche ad OSM. Per ora non permette la
> cancellazione (per fortuna). Questo ha introdotto un aumento di note sulla
> mappa, molte volte criptiche, perché l' utente non lascia commenti, e
> peggio ancora modifiche di questo genere [1].
> Il name del Duomo di Milano è già stato modificato 3 volte ed il nostro
> amico Alecs01 ha ripristinato il name. Come possiamo correre ai ripari?
> Contattiamo tutti gli utenti MAPS.ME?? Rischiamo dei danni seri.
> Grazie
>
> [1] https://www.openstreetmap.org/way/290222578
>
> Andrea Lattmann
>
> ___
> 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] MAPS.ME maggior diffusione OSM inizio nuovi problemi... Seri!

[Max1234Ita]

Probabilmente gli utenti di Maps.me vanno "educati" al rispetto di certe
regole che sono ben note ai mappatori OSM "Tradizionali".

Mi chiedo: Ma chi fa questo tipo di modifiche dovrà ben usare un account
OSM... o no?
Se è così, non varrebbe anche in questo caso la direttiva di correggere
l'errore e lasciare un commento sul changeset? Già questo dovrebbe avere un
certo effetto sui nuovi mappatori, che quasi certamente sono animati da
buona volontà.

Poi, certo, forse sarebbe anche il caso che Maps.me spiegasse ai suoi utenti
almeno i concetti di base della mappatura, o quantomeno mettesse degli
avvisi, indicando con chi mettersi in contetto e dove trovare non dico un
tutorial completo, ma almeno le informazioni di base per evitare di far
danni...

Ovviamente, il tutto, IMHO; se poi sia fattibile e come, purtroppo, non lo
so.
Max



--
View this message in context: 
http://gis.19327.n5.nabble.com/MAPS-ME-maggior-diffusione-OSM-inizio-nuovi-problemi-Seri-tp5874719p5874740.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] [OT] discutibili cancellazioni, modifiche ed integrazioni

[Martin Koppenhoefer]

sent from a phone

> Il giorno 04 giu 2016, alle ore 11:22, Andrea Lattmann 
>  ha scritto:
> 
> C'è un aumento di modifiche con errori, come risolvere il problema? 
> Contattare gli utenti MAPS.ME o "rincorrerli" nelle modifiche?


potrebbe essere il modo in cui vengono presentati i tags, o il sistema osm in 
generale  in maps.me, la causa dei problemi? È giusto segnalare agli utenti gli 
errori presenti negli edits, ma più importante ancora andare alla fonte. Ti va 
di scrivere in lista talk@osm? Sono sicuro che seguono e si farebbe presente il 
presunto problema anche agli altri mappatori che non leggono talk-it


ciao,
Martin 



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

Re: [OSM-talk-nl] Verplaatsen bushaltes/routes Amstelstation

[Jo]

Als je wilt, kunnen we vanavond een hangout doen. Dan leg ik je het een en
ander uit over OV met JOSM.

Polyglot
Op 4-jun.-2016 2:13 PM schreef "Freek Dijkstra" :

> Goededag,
>
> Het busstation bij Amsterdam Amstel is verplaatst, en zal later nogmaals
> verplaatst worden (zie https://www.amsterdam.nl/amstelstation).
>
> Er lopen busroutes over dit terrein, en die wil ik graag ook
> verplaatsen. Wat is de beste manier om routes te bewerken? Ik gebruik
> eigenlijk alleen de online editor op osm.org, maar die interface is niet
> helemaal geschikt.
>
> Wat ik nu doe is:
> 1. Selecteer een straat of bushalte
> 2. In het "Edit feature" paneel, klik op een relatie. Bijvoorbeeld Bus
> Route lijn 240.
> 3. In het "Edit feature" paneel, staat een lijst van "members": de
> straten (en haltes?) van de route.
>
> Ik loop echter tegen een paar beperkingen aan:
> - ik kan de volgorde van members niet verplaatsen door deze omhoog of
> omlaag te verslepen.
> - ik kan wel een "relatie" toevoegen, maar zo te zien geen "member".
> - een aantal van de members heeft als beschrijving "",
> en ik zie niet hoe ik deze straten en haltes zichtbaar kan maken in de
> lijst.
>
> Heeft iemand advies hoe een halte en route van een buslijn makkelijk te
> wijzigen is?
>
> Groet,
> Freek
>
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl
>
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

[OSM-talk-nl] Verplaatsen bushaltes/routes Amstelstation

[Freek Dijkstra]

Goededag,

Het busstation bij Amsterdam Amstel is verplaatst, en zal later nogmaals
verplaatst worden (zie https://www.amsterdam.nl/amstelstation).

Er lopen busroutes over dit terrein, en die wil ik graag ook
verplaatsen. Wat is de beste manier om routes te bewerken? Ik gebruik
eigenlijk alleen de online editor op osm.org, maar die interface is niet
helemaal geschikt.

Wat ik nu doe is:
1. Selecteer een straat of bushalte
2. In het "Edit feature" paneel, klik op een relatie. Bijvoorbeeld Bus
Route lijn 240.
3. In het "Edit feature" paneel, staat een lijst van "members": de
straten (en haltes?) van de route.

Ik loop echter tegen een paar beperkingen aan:
- ik kan de volgorde van members niet verplaatsen door deze omhoog of
omlaag te verslepen.
- ik kan wel een "relatie" toevoegen, maar zo te zien geen "member".
- een aantal van de members heeft als beschrijving "",
en ik zie niet hoe ik deze straten en haltes zichtbaar kan maken in de
lijst.

Heeft iemand advies hoe een halte en route van een buslijn makkelijk te
wijzigen is?

Groet,
Freek

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

Re: [Talk-de] EnBW erneuert Ladesäulen für Elektroautos

[Angie]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> 

> Schaut bei Gelegenheit in eurer Nähe ob die Daten noch aktuell sind.
> 
Ich möchte mal Verallgemeinern:
Hier : http://osm.org/go/0JFSCY89B?m=
ist eine Elektroladesäule vorhanden, wird aber nicht gerendert.
Hat das einen Grund?

MfG Angie


- -- 

- --BEGIN H*KEY BLOCK-
v4sw5CPUhw5pr5FPck2ma8u7Lw3XGm1l7ELi3JNTe7t4TNDVb5Oen5g3/2ZMa5XsSr1p
md575107a5d52c10f952288d17f2df7af632
- ---END H*KEY BLOCK--
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAldSurEACgkQbWutCqbzQO3RrQCgssaEi5Ke5NpWpATINSX+Ihjw
vTwAn0A6Gvk4Pr2S5bUENIGdospTcMye
=WCsi
-END PGP SIGNATURE-

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

Re: [Talk-us] Best practices for dealing with old TIGER tags?

[Greg Troxel]

Kevin Kenny  writes:

> OK, 'residential' if it looks like 'subdivision', 'unclassified'
> otherwise (as long as it's drivable in, say, my daughter's car rather
> than my 4-wheeler). Got it.

I also see a distinction between residential/unclassified as denoting a
legal road (around me, carved-out parcel wise from the surrounding land)
vs track and some service denoting a non-legal-road.  However, others
see the physical and legal attributes as separate.

If you do change a legal road to track because of poor condition, please
add access=yes if that is how it is.  highway=residential has a pretty
safe access=yes default, and I find that most highway=track are not
actually access=yes, even though most do not have tags.  This is further
messy on rendering, as it might be that tracks should be rendered with
an access color if they are access=yes, and not colored if they are
access=private.

> I suspect that 'residential'/'unclassified' right now is almost a
> difference without a distinction.

In the US, that's true.  Driving in Scotland recently gave me more
insight into the UK origins of the classification.

> I suppose that 'residential' might be a weak indication to a router to
> avoid the route, but the consequences of getting it wrong don't appear
> to be terribly severe.  Which is a relief.

I would say that a router avoiding residential is incorrect, unless it's
a tiny bit of avoidance.   It should really be about speeds, width,
lights, etc.

As for where Richard Welty draws the line, if there are a lot of houses
on 4 acre lots, I don't think that's iffy.  The questions to me is not
subdivision but

  whether most of the landuse along the road is residential or not

and the much harder

  whether much of the traffic is to/from residential vs other, which is
  even harder for collector roads to neighborhoods and what you call
  through

in the end I tink where this line is drawn is very far down on the OSM
problem list.


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

Re: [Talk-it] MAPS.ME maggior diffusione OSM inizio nuovi problemi... Seri!

[Andrea Lattmann]

Altro name con 2 lingue...

https://www.openstreetmap.org/node/4225167189

Andrea Lattmann

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

Re: [Talk-it] [OT] discutibili cancellazioni, modifiche ed integrazioni

[Andrea Lattmann]

>è fortemente consigliato di aggiungere >un vostro commento al relativo
>changeset(s). Secondo la DataWorkingGroup è il metodo preferito di
>comunicare, in quanto è pubblico e rimane traccia, e viene anche
>notificato il creatore del changeset via email.

Sono d'accordo ed è quello che faccio. Il problema è che non fai in tempo a 
sistemare una cosa che trovi fuori posto un altra. C'è un aumento di modifiche 
con errori, come risolvere il problema? Contattare gli utenti MAPS.ME o 
"rincorrerli" nelle modifiche?

Andrea Lattmann

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

Re: [OSM-talk-fr] ERDF (et RFF) ont changé de nom

[Éric Gillet]

Le 4 juin 2016 à 05:48, JB  a écrit :

> Le 03/06/2016 à 23:26, DH a écrit :
>
>> Justement l'idée c'est d'avoir, à terme, une super relation "Réseau Ferré
>> National" avec operator=SNCF Réseau (1), dedans toutes les relations de
>> lignes composées des relations de voies, composées des tronçons, les
>> relations de gares
>
> Bœurk… Je suis le seul à trouver ça affreux ?


Je suis aussi de cet avis. Les relations ne sont pas des catégories
.
Chaque élément (tronçons, gares, etc.) sont gérés individuellement et donc
méritent un tag operator=*, un gauge=*, etc.
L'usage de relation permet de lier plusieurs éléments entre eux, comme un
réseau de voie ferrées, un itinéraire ou autre.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendus OSM des villes

[osm . sanspourriel]

l'info capital=6 a un an d'âge sur l'admin_centre et 5 mois sur la relation.


Le 2016-06-04 à 02:06, Philippe Verdy - verd...@wanadoo.fr a écrit :
Note: au niveau 6 il faut du temps pour la mise à jour. Ici, Saint-Avé 
a été incorrectement tagué avec un statut plus important ou au moins 
aussi important que Vannes, mais c'est corrigé depuis un moment.


Malheureusement avant que le rendu soit mis à jour... (/dirty ne 
fonctionne pas au niveau 6, il est bloqué (avec un message d'erreur 
envoyé retourné en HTTP au lieu du HTTPS, donc qui merde et ne 
s'affiche pas, à cause d'un problème de config sur le serveur de rendu 
FR)... il faut attendre un mois ou plus pour un raffraichissement à ce 
niveau)


Le 4 juin 2016 à 00:48, > a écrit :


C'est vrai que le rendu OSM-FR est nettement moins mauvais mais
lui aussi affiche Saint-Avé :

http://b.tile.openstreetmap.fr/osmfr/6/31/22.png

http://b.tile.openstreetmap.fr/osmfr/6/31/22.png


Je parle bien de niveaux auxquels on s'attend à voir des villes
par des quartiers (ici niveau 6).


Le 2016-06-04 à 00:30, Philippe Verdy - verd...@wanadoo.fr
 a écrit :

Le rendu Mapnik par défauit d'OSM ne fait aucun classement de
priorité des libellés. Ou si classement il y a c'est sur des
critères complètement stupides qui cachent l'essentiel presque
partout.

Note: passé un certain niveau de zoom, les villes n'apparaisent
plus du tout, c'est normal de voir alors les quartiers.

Mais tout ça n'a jamais été correctement réglé sur ce rendu
"merdique" (le mot est faible).

Comparez avec le rendu FR, ou les autres rendus (Mapquest,... ),
c'est nettement plus cohérent. Mais les développeurs de la
fondation n'ont jamasi pris le temps de corriger ça dans leur
rendu et se sont concentrés d'abord sur des détails avant
l'essentiel, qui est ce qui pourtant est le plus visible. Cela ne
rend pas service du tout à OSM et incite même bien des sites à ne
PAS utiliser OSM mais encore préférer Google Maps !


Le 3 juin 2016 à 21:17, > a écrit :

Sur la couche transport, c'est même un quartier de Vannes qui
se substitue à Vannes :


http://www.openstreetmap.org/way/213906166#map=9/47.6575/-2.7383=T

Vous voyez quelque chose d'incorrect dans les données ou ce
sont les rendus qui ne rendent pas très bien les agglomérations ?

Jean-Yvon


Le 2016-06-02 à 23:37, osm.sanspourr...@spamgourmet.com
 a écrit :


Vannes  est la
préfecture du Morbihan :

admin_level

8


capital
   6
name

Vannes
population

52515

Le nœud Vannes
 lui-même
comporte aussi capital=6 et la population.

Un peu au nord se trouve la petite ville de Saint-Avé
 :

admin_level

8


name

Saint-Avé
population

10385


Certains rendus ne semblent utiliser ni le capital (ici
6=préfecture) ni la population mais juste place=town avec
affichage de haut à gauche en bas à droite.
Résultat : OSM-FR affiche Saint-Avé simple ville dans la
banlieue de Vannes, plutôt que Vannes 5 fois plus important
et préfecture du Morbihan.
Il n'est pas possible d'organiser le tracé par
coalesce(capital,15) croissant puis par
coalesce(population,0) décroissant ?

Jean-Yvon


___
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] [OT] discutibili cancellazioni, modifiche ed integrazioni

[Federico Cortese]

2016-06-04 10:48 GMT+02:00 Martin Koppenhoefer :
>
> non è così OT, se notate qualche edit strano o caso discutibile, è fortemente 
> consigliato di aggiungere un vostro commento al relativo changeset(s). 
> Secondo la DataWorkingGroup è il metodo preferito di comunicare, in quanto è 
> pubblico e rimane traccia, e viene anche notificato il creatore del changeset 
> via email.
>
+1 è vero è il metodo migliore, mi devo abituare ad usarlo.
Ciao
Federico

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

Re: [Talk-it] [OT] discutibili cancellazioni, modifiche ed integrazioni

[Martin Koppenhoefer]

sent from a phone

> Il giorno 04 giu 2016, alle ore 09:39, Andrea Lattmann 
>  ha scritto:
> 
> Scusate per l' OT, ma mi sa che dobbiamo rispolverare l' idea di mandare una 
> mail ad ogni changeset all' autore originale


non è così OT, se notate qualche edit strano o caso discutibile, è fortemente 
consigliato di aggiungere un vostro commento al relativo changeset(s). Secondo 
la DataWorkingGroup è il metodo preferito di comunicare, in quanto è pubblico e 
rimane traccia, e viene anche notificato il creatore del changeset via email.

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

[Talk-de] EnBW erneuert Ladesäulen für Elektroautos

[rza31]

Hallo,

die EnBW ersetzt ihre Ladesäulen der 1. Generation. Wenig frequentierte
Standorte werden abgebaut.

Schaut bei Gelegenheit in eurer Nähe ob die Daten noch aktuell sind.

Suche Ladesäulen: http://overpass-turbo.eu/s/gCg

Viele Grüße

rza31

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

Re: [Talk-it] [OT] discutibili cancellazioni, modifiche ed integrazioni

[Andrea Lattmann]

>Sul aspetto più informatico, concordo >con le corrette osservazioni fatte in 
>>particolare da Andrea Albani ma anche >sul fatto che "se uno fa ciò che vuole 
>è >un macello!" (Andrea Lattmann) e sulla >soluzione che propone: "più che una 
>>validazione sarebbe necessario una >segnalazione: così se uno vuole, può 
>>andarsi a vedere il changeset con le >modifiche/cancellazioni effettuate e 
>può >eventualmente contattare l' utente e >chiedere spiegazioni."

Scusate per l' OT, ma mi sa che dobbiamo rispolverare l' idea di mandare una 
mail ad ogni changeset all' autore originale, per aver un maggior controllo. 
Leggete la mia mail riguardo MAPS.ME... 

Andrea Lattmann

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

[Talk-it] MAPS.ME maggior diffusione OSM inizio nuovi problemi... Seri!

[Andrea Lattmann]

Ciao ragazzi, come da oggetto, con le/la nuova versione di MAPS.ME da la 
possibilità di effettuare modifiche ad OSM. Per ora non permette la 
cancellazione (per fortuna). Questo ha introdotto un aumento di note sulla 
mappa, molte volte criptiche, perché l' utente non lascia commenti, e peggio 
ancora modifiche di questo genere [1].
Il name del Duomo di Milano è già stato modificato 3 volte ed il nostro amico 
Alecs01 ha ripristinato il name. Come possiamo correre ai ripari? Contattiamo 
tutti gli utenti MAPS.ME?? Rischiamo dei danni seri. 
Grazie

[1] https://www.openstreetmap.org/way/290222578

Andrea Lattmann

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

Re: [OSM-talk-nl] BAG-plugin

[Johan C]

Hoi Ronald

Hij is zeker nog niet af, wat komt doordat het nog best ingewikkeld is om
de BAG en OSM met elkaar te vergelijken. Daar komt bijvoorbeeld nog bij dat
er sinds een week een probleem is met importeren vanuit de BAG WFS.

Wordt vervolgd...

Johan
Op 4 jun. 2016 08:42 schreef "Ronald Stroethoff" :

> Enige maanden geleden waren er meldingen over een nieuwe versie van de BAG-
> plugin.
> Toen werd er gemeld dat hij klaar was maar dat hij door een selecte groep
> in
> de praktijk getest moest worden.
> We zijn nu enige maanden verder en ik ben benieuwt wat de status daarvan
> is.
> Kan iemand mij daarover wat meer vertellen?
>
> Ronald
>
>
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl
>
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

[OSM-talk-nl] BAG-plugin

[Ronald Stroethoff]

Enige maanden geleden waren er meldingen over een nieuwe versie van de BAG-
plugin.
Toen werd er gemeld dat hij klaar was maar dat hij door een selecte groep in 
de praktijk getest moest worden.
We zijn nu enige maanden verder en ik ben benieuwt wat de status daarvan is.
Kan iemand mij daarover wat meer vertellen?

Ronald


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