Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

2017-09-26 Thread Stefano
2017-09-26 19:43 GMT+02:00 Yves :

> I think that the underlying issue in wikidata tags is that they are
> external IDs. Not human readable, they cannot be entered 'by hand' nor
> verified on the ground.
>

Yes, it's an external ID, but it acts as intermediary with other databases,
because Wikidata acts as a central repository for IDs (see
https://cacm.acm.org/magazines/2014/10/178785-wikidata/fulltext). One could
perform a reconciliation of its database against Wikidata instead of
against OSM, and get a match 'for free'.
We can't add OSM ids in WD because they aren't stable, so Wikidata IDs
could be the stable IDs for certain classes of objects (those "worth" of
some description in another project?).

"Entered by hand" they can't be in the same way as Wikipedia entries can't
(you add a wikipedia tag hoping someone will fill the "red link" on that
wikipedia page?)



> Once you accept them in OSM, you can't really complain about bots.
>
> Yves (who still think such UIDs are only needed for the lack of good query
> tools).
>
>
>
Stefano
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [Talk-at] Es geht alles gegen null

2017-09-26 Thread Borut Maricic
Muss gestehen, dass ich in diesem Thread nicht alles
durchgelesen habe.

Habe in JOSM 12901 gerade bemerkt, dass es beim Uploaden
eine Option "I would like someone to review my edits" zum
abhacken gibt, die dann zu einem Changeset-Tag
review_requested=yes führt. Scheint mir neu zu sein und ich
finde die Idee nicht schlecht.



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


Re: [Talk-it] Aiuto su conditional restrictions

2017-09-26 Thread Martin Koppenhoefer
2017-09-26 19:46 GMT+02:00 Marcello :

>
> secondo la segnaletica della foto [1].



le collezioni di cartelli del genere sono veramente assurdi, chi fa questo
ha sbagliato professione e dovrebbe scrivere libri invece di fare cartelli.
L'unico modo e fermarsi davanti con la macchina, leggersi tutto il testo,
chiamare il numero telefonico indicato e farsi spiegare cosa intendono ;-).
Ogni giorno.

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


Re: [Talk-it] Aiuto su conditional restrictions

2017-09-26 Thread Damjan Gerl

26.09.2017 - 19:46 - Marcello:

Salve,

i comuni certo non facilitano la vita ai mappatori e non amano la
semplificazione, ad esempio volevo inserire le restrizioni di accesso
secondo la segnaletica della foto [1].

Al momento ho inserito:
access=private
disabled=yes
emergency=yes
foot=yes
goods=delivery

Vorrei aggiungere anche access:conditional=yes in base agli orari,
giorni della settimana e mesi, ma sono talmente tante le condizioni che
mi sto intrecciando sempre più e non ne esco. Qualcuno ha dei suggerimenti?

Grazie a tutti

[1] https://www.dropbox.com/s/a26h145wdkw7nn6/20170920_102002.jpg?dl=0



Ecco la stringa per gli orari (supponendo che l'ultima riga con la croce 
valga come quella prima - domenica e festivi):


Apr 14-Oct 29: Mo-Th 10:00-24:00, Fr-Sa,PH -1 day 19:00-01:00, Su,PH 
14:00-01:00, Oct 30-Apr 13: Fr,Sa,PH -1 day 19:30-01:00, Su,PH 14:00-01:00



Damjan

PS: per la verifica della sintassi degli orari/opening_hours consiglio 
l'uso del tool http://openingh.openstreetmap.de/evaluation_tool/


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


Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread mmd
Am 26.09.2017 um 12:39 schrieb Safwat Halaby:
> On Tue, 2017-09-26 at 11:46 +0200, Jo wrote:

>>
>> Overpass API is definitely your friend. Version 3 doesn't mean much
>> though.
>> Do you mean all bus stops with a public_transport tag?
> 
> Thanks for the reply.
> 
> By version 3, I mean a particular historic version of the OSM element. 
> 
> For instance, see "Version #3" of this bus stop:
> 
> https://www.openstreetmap.org/node/1802982884/history
> 
> I need all "version #3" of all bus stops that have a
> "source=israel_gtfs_v1" in Israel. As far as I know. Overpass can only
> fetch the latest version. Can overpass directly fetch version #3?
> 

That's not yet possible with release 0.7.54.

A future Overpass release will allow you to filter for a specific
version of an object, which exists at a given point in time. That's
either NOW, or the date you specify via [date: ...].

A query for all version 3 objects would only work, if you can find such
a point in time, where all of those objects are valid. If there isn't
such date, you need to try several queries with varying date.

Here's some to try out in the meantime: http://overpass-turbo.eu/s/rZc


-- 




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


Re: [Talk-it] Sito statistiche "Dapal"

2017-09-26 Thread Lorenzo "Beba" Beltrami
+1 anch'io!

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


Re: [Talk-it] Chiusura fontanelle a Roma

2017-09-26 Thread Martin Koppenhoefer
2017-09-26 18:47 GMT+02:00 Fabrizio :

> C'è già una mappatura in corso di quelle chiuse http://www.reter.org/blog/
> index.php/notizie/reter-news/59-closed-fontanelle-i-nasoni-
> a-secco-nasonydry
>


ma è ancora attuale? Io sono stato un po' in giro questi giorni e non ho
trovato chiusa nessuna.

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


Re: [Talk-it] Sito statistiche "Dapal"

2017-09-26 Thread Martin Koppenhoefer
certo, +1 anche da me

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


Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread Safwat Halaby
link fix:
 https://forum.openstreetmap.org/viewtopic.php?id=16738

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


Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread Safwat Halaby
On Tue, 2017-09-26 at 17:08 -0400, john whelan wrote:
> Please do not do this globally.
> 

Of course not. I wouldn't deploy anything globally without prior
discussion.

What I meant was the script is not Israel-specific, and anyone who
knows their provider has some reasonable accuracy could use it. It
allows incremental GTFS updates where mapper-submitted accuracy fixes
are not overridden by the next update.

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


Re: [Talk-it] Changeset auto-matching.

2017-09-26 Thread Martin Koppenhoefer
c’è comunque una discussione su questo in talk che non è finita...


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


Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread Safwat Halaby
On Tue, 2017-09-26 at 14:12 +0200, Frederik Ramm wrote:
> 
> Are all these automatic edits at least discussed on the Israeli
> mailing
> list, or is this a free-for-all where anyone who knows how to write a
> script runs over all bus stops in Israel again and again?
> 
> Bye
> Frederik
> 

Why are you automatically assuming the worst? I have, and I am,
extensively discussing fixing the import mess. Even the previously
messy imports by the other users were discussed and were fairly
coordinated. See this: https://forum.openstreetmap.org/viewtopic.php?id
=16738



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


Re: [Talk-it] Metro Roma

2017-09-26 Thread Martin Koppenhoefer
2017-09-26 8:46 GMT+02:00 Dino Michelini :

> Ciao, ho fatto una verifica. Per il tratto urbano della FL3 ed è tutto ok;
> tunnel=yes è già presente nelle stazioni sotterranee.
>


si, ma non è una metro, è un treno.



> Le stazioni della "linea A" (https://it.wikipedia.org/
> wiki/Linea_A_(metropolitana_di_Roma)) sono sotterranee mentre sulla
> "linea B" (https://it.wikipedia.org/wiki/Linea_B_(metropolitana_di_Roma))
> la situazione è più articolata: le stazioni comprese nel tratto Piramide -
> Eur Magliana sono in superficie (livello 1 dal piano stradale ad eccezione
> di Piramide che è sotto il piano stradale ma non è sotterranea ma senza
> galleria/tunnel).
>


anche Garbatella è al livello -1 rispetto alla strada (dalla parte dove si
entra). Non è un problema, una metro (subway) può andare sia in superficie,
che sopraelevato che sotto terra, la cosa importante è che non abbia
passaggi a livello con le strade.

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


Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread Safwat Halaby
On Tue, 2017-09-26 at 08:50 -0400, john whelan wrote:
> I suggest pulling in the country file and if need be chop it up to
> load
> into JOSM.  Load up the latest bus stops in a different layer then
> use the
> todo plugin and go through them one at a time cleaning them up that
> way.
> 
> Note that the GTFS file bus stop location may not be accurate, some
> bus
> stops are known to be 100 meters out, it depends on the provider.  If
> you
> have a system that announces bus stops for partially sighted people
> then
> that is an indication they should be fairly good but check with the
> provider.  Even when they are accurate they can still be out by a few
> meters, locally one was in the middle of a road junction so they do
> need
> verifying.
> 

We are well aware that GTFS accuracy is not perfect. (Though nobody
reported a 100-meter deviation so far). A potential solution, which
could also work globally, is discussed below. I already have a
(somewhat) working prototype. I'll look for other solutions too.

https://forum.openstreetmap.org/viewtopic.php?id=16738=3

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


Re: [OSM-talk] Label language on the Default stylesheet

2017-09-26 Thread Martin Koppenhoefer
for the record: using Latin would be the completely wrong message we could
send out IMHO. It would make us look like an elitist circle [1] and would
make many people feel rejected, or at least make them turn away as soon as
they get to know about it.

Cheers,
Martin


[1] sometimes you already can get this impression about OSM, although it is
a different bunch of elitists (computer science) than those typically
studying Latin.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread john whelan
Just a clarification, I'm not against imports and I have been involved in a
number as I'm sure Frederik will recall but it's important to me that the
data to be imported is of good quality, is correctly licensed and is merged
with existing data.  In the case of bus stops that means including tags
previously mapped such as shelter and wheelchair=yes and not just deleting
the old and dropping in the new.

Mappers who have spent time tagging deserve their efforts should be
recorded.  Although I sometimes have my doubts about a mapper who has
mapped once for half an hour and added a very inaccurate building tagged as
an apartment block in a small African village but in general it should be
followed.

Cheerio John

On 26 Sep 2017 5:08 pm, "john whelan"  wrote:

> >We are well aware that GTFS accuracy is not perfect. (Though nobody Reported
> a 100-meter deviation so far). A potential solution, which could also
> work globally, is discussed below.
>
> Some University researchers who were looking at the GTFS files noted the
> problem sometime ago in the US.  One provider was a couple of hundred
> metres out on bus stop location.  Locally they were a little better but it
> was only when the bus announcement system came in and they very very
> carefully measured the location of each bus stop to comply with the
> provincial instructions that the GTFS file became at all usable and even
> then it took a dedicated team to do it and it wasn't a straight import.
>
> Personally unless you can confirm the accuracy of the bus stops my feeling
> is no data is better than poor data that cannot be trusted.
>
> Please do not do this globally.
>
> Cheerio John
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Label language on the Default stylesheet

2017-09-26 Thread Martin Koppenhoefer


sent from a phone

> On 26. Sep 2017, at 23:58, Andy Mabbett  wrote:
> 
> Wherever I go in the world, I try to make some improvements to OSM. Am
> I then a local mapper? In Jakarta, Doha, Cairo, Larnaca, Istanbul, or
> Warsaw?


IMHO you are a local mapper in places that you know very well, either because 
you live there or because you have a good reason to go there often, e.g. for 
work, friendship etc.

Being able to conduct a survey (because you are there and have time and 
interest) makes your mapping (IMHO) more valuable than that of people remotely 
mapping without first hand knowledge of the area, but a local? I’d reject this.

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


[OSM-talk] Fixing wiki* -> brand:wiki*

2017-09-26 Thread Yuri Astrakhan
Here is a query that finds all wikidata IDs frequently used in
"brand:wikidata", and shows OSM objects whose "wikidata" points to the
same. I would like to replace all such wikidata/wikipedia tags with the
corresponding brand:wikidata/brand:wikipedia.  Most of them are in India,
but there are some in Europe and other places.  This query can be used
directly from JOSM as well.

http://tinyurl.com/y72afjpy

BTW, this type of queries might be good for maproulette challenges once
they can work more like osmose.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

2017-09-26 Thread Martin Koppenhoefer
2017-09-26 5:14 GMT+02:00 Marc Gemis :

> This might also mean that
> you have to discuss it via Telegram, Facebook, email, IRC, etc.
> depending on where that local community is.
>
> The talk mailing list is not sufficient.



I think this is problematic. If the local community uses a paid service for
communication you'd have to pay in order to speak to your fellow mappers?

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


Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread john whelan
One last point have you confirmed the Open Data license is acceptable to
OSM?  It took me about five years and a great deal of effort to ensure and
confirm the licenses were compatible to get my GTFS bus stops in.

The OSM legal working group eventually agreed they were but noted they
would want to confirm every other Canadian municipal license Open Data
licence before agreeing they were compatible.

The LWG are volunteers and I understand there is a small backlog.

Cheerio John

On 26 Sep 2017 5:18 pm, "john whelan"  wrote:

> Just a clarification, I'm not against imports and I have been involved in
> a number as I'm sure Frederik will recall but it's important to me that the
> data to be imported is of good quality, is correctly licensed and is merged
> with existing data.  In the case of bus stops that means including tags
> previously mapped such as shelter and wheelchair=yes and not just deleting
> the old and dropping in the new.
>
> Mappers who have spent time tagging deserve their efforts should be
> recorded.  Although I sometimes have my doubts about a mapper who has
> mapped once for half an hour and added a very inaccurate building tagged as
> an apartment block in a small African village but in general it should be
> followed.
>
> Cheerio John
>
> On 26 Sep 2017 5:08 pm, "john whelan"  wrote:
>
>> >We are well aware that GTFS accuracy is not perfect. (Though nobody Reported
>> a 100-meter deviation so far). A potential solution, which could also
>> work globally, is discussed below.
>>
>> Some University researchers who were looking at the GTFS files noted the
>> problem sometime ago in the US.  One provider was a couple of hundred
>> metres out on bus stop location.  Locally they were a little better but it
>> was only when the bus announcement system came in and they very very
>> carefully measured the location of each bus stop to comply with the
>> provincial instructions that the GTFS file became at all usable and even
>> then it took a dedicated team to do it and it wasn't a straight import.
>>
>> Personally unless you can confirm the accuracy of the bus stops my
>> feeling is no data is better than poor data that cannot be trusted.
>>
>> Please do not do this globally.
>>
>> Cheerio John
>>
>>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [Talk-it] Chiusura fontanelle a Roma

2017-09-26 Thread Cascafico Giovanni
Diverse segnalazioni ho visto riportano date piuttosto recenti (22-25
settembre) sotto la foto.

Non so se sono ricavate dagli exif o se un reddatore le assegna.

Il 26/set/2017 22:10, "Martin Koppenhoefer"  ha
scritto:

>
>
> 2017-09-26 18:47 GMT+02:00 Fabrizio :
>
>> C'è già una mappatura in corso di quelle chiuse
>> http://www.reter.org/blog/index.php/notizie/reter-news/59-
>> closed-fontanelle-i-nasoni-a-secco-nasonydry
>>
>
>
> ma è ancora attuale? Io sono stato un po' in giro questi giorni e non ho
> trovato chiusa nessuna.
>
> Ciao,
> Martin
>
> ___
> 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] Sito statistiche "Dapal"

2017-09-26 Thread liste DOT girarsi AT posteo DOT eu
Rimando per qualche problema mio con la mail.


> Il 26/09/2017 16:53, liste DOT girarsi AT posteo DOT net ha scritto:
>> +1 anche per me.
>>
>> Domanda, intendi installarlo su wikimedia labs?
>>
>> Quanto codice c'è da rivedere, lo hai già revisionato?
>>
> 
> 


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

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


Re: [OSM-talk] Label language on the Default stylesheet

2017-09-26 Thread Martin Koppenhoefer
2017-09-26 6:00 GMT+02:00 Oleksiy Muzalyev :

> But the Latin language does exist, and its popularity is growing [1].
>


see, they also mention Greek ;-)

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


Re: [OSM-talk] Fixing OSM wikipedia redirects

2017-09-26 Thread Safwat Halaby
On Mon, 2017-09-25 at 23:11 -0400, Yuri Astrakhan wrote:
>  Fixing them by hand seems like a huge waste of the
> community time

I agree. This is purely mechanical work. Drudgery is evil.

I'm willing to try writing a script once I finish my other scripting
projects. This should be straightforward.

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


Re: [OSM-talk] Label language on the Default stylesheet

2017-09-26 Thread Daniel Koć

W dniu 26.09.2017 o 23:00, Martin Koppenhoefer pisze:
for the record: using Latin would be the completely wrong message we 
could send out IMHO. It would make us look like an elitist circle [1] 
and would make many people feel rejected, or at least make them turn 
away as soon as they get to know about it.


I would choose languages to reach as many people as possible:

https://en.wikipedia.org/wiki/List_of_languages_by_total_number_of_speakers#Ethnologue_.282017_20th_edition.29

--
"Probably it's an eternal problem - too many chiefs, too few Indians" [O. 
Muzalyev]


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


Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread john whelan
>We are well aware that GTFS accuracy is not perfect. (Though nobody Reported
a 100-meter deviation so far). A potential solution, which could also work
globally, is discussed below.

Some University researchers who were looking at the GTFS files noted the
problem sometime ago in the US.  One provider was a couple of hundred
metres out on bus stop location.  Locally they were a little better but it
was only when the bus announcement system came in and they very very
carefully measured the location of each bus stop to comply with the
provincial instructions that the GTFS file became at all usable and even
then it took a dedicated team to do it and it wasn't a straight import.

Personally unless you can confirm the accuracy of the bus stops my feeling
is no data is better than poor data that cannot be trusted.

Please do not do this globally.

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


Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread Safwat Halaby
I'd like to point out (as I pointed out in the sub-threads), that I
solved this problem simply by fetching the changeset which introduced
v3.

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


Re: [OSM-talk] Label language on the Default stylesheet

2017-09-26 Thread Andy Mabbett
On 25 September 2017 at 07:14, Jo  wrote:

> The purpose of the default rendering is to give feedback to mappers.

I'd love to see some stats on how many people visit that map, and their reasons.

Fancy a wager on the percentage that are mappers?

What about people who have no interest in becoming mappers, but whom
we want to convert to being users of OSM data? Or donors of data?

> Preferably local mappers, so having the map rendered in local languages
> shouldn't be a problem.

Wherever I go in the world, I try to make some improvements to OSM. Am
I then a local mapper? In Jakarta, Doha, Cairo, Larnaca, Istanbul, or
Warsaw?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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


Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

2017-09-26 Thread Andy Townsend

On 26/09/2017 03:40, Yuri Astrakhan wrote:

... I have been blocked by Andy Townsend with the following message.

Let's begin at the beginning - this was a "0-hour block" - you weren't 
prevented from using the API for _any_ period of time, merely forced to 
read this message first.  This was a last resort - many other attempts 
at communication have been made over at least the last 10 months (since 
November 2016 - https://www.openstreetmap.org/changeset/43749373 ).  The 
issues that I raised back then are still true today - see 
https://lists.openstreetmap.org/pipermail/talk/2017-September/078780.html 
for more details.  It makes no sense to mechanically copy a wikidata 
value to OSM when the wikidata object expresses only part of the sense 
of the wikipedia page.


Simple example in case things are still not clear:

1) Imagine there are two objects in OSM - a village and an admin area 
containing that village.

2) Wikipedia only has one page for a "village and an admin area"
3) The wikidata page (probably created by a bot) is only for the village
4) Linking the OSM admin area to the wikidata page for the village is an 
error.


This is the sort of thing that you've been doing again and again for the 
last 10 months.


A few interesting semi-relevant statistics so far:  the number of 
discovered links to disambig pages is now back to over 800, even 
without 100k+ untaged ways. And there are almost 38,000 osm objects 
where wikipedia tag does not correspond with wikidata tag. The number 
is very high, but fixing them should be semi-automated, as most of 
them are redirects. TBD.


There are a lots of possibilities here.  Maybe the OSM object shouldn't 
have a wikipedia entry at all.  Maybe it's significantly changed since 
the link was added, and should be changed.  It needs someone with 
real-world knowledge of the OSM object to update the links - anything 
else is just guessing, and has no place in OSM.


If by "semi-automated" you mean a human-centric approach like Kort, 
MapRoulette, StreetComplete et al then fine - but that's not been your 
approach so far.




Here's Andy's message, with my inlined replies. I think that almost 
all of the raised points have been raised and answered in our previous 
discussion, but I feel it is my responsibility to present them again.


You're conducting an import of known bad data (your own changeset
comments say "Further cleanup will be done using...").


Per previous description, the existing data is already bad, and I am 
simply making it possible to identify it, after discussing it on this 
thread.
No, that is untrue.  See e.g. 
https://www.openstreetmap.org/changeset/52002597 .





You are wilfully ignoring the feedback that you're receiving now
and have received in the past. A lot of issues have been raised
about the quality of your edits - see
http://resultmaps.neis-one.org/osm-discussion-comments?uid=339581
. In many cases you seem to agree that you're adding rubbish, and
yet you continue.

You seem to be suggesting (in
https://lists.openstreetmap.org/pipermail/talk/2017-September/078767.html
) that "the community" clean up your mess. This is not the way
that OpenStreetMap works - if an individual is adding data to it
(especially large quantities of data) then it is their
responsibility to ensure that the data that they are adding is
valid, or at least as valid as the data that is already there.


Again, no, I am identifying rubbish, not introducing it, and I am very 
actively replying to every comment I receive.
You are not actually _resolving_ any of the problems that people are 
finding with the edits that you are making.  See for example 
https://www.openstreetmap.org/changeset/52341792 .  In that example 
someone says that you added a wikidata tag in error.  You agree that you 
added it in error (and in fact a whole category of the tags that you've 
added is in error - I've commented on a couple more within the last 
hour).  You have not done anything to resolve this error that you have 
introduced into OSM .


Going further back, in your replies to changeset comments you've said 
things like "I have already stopped changing any objects except the 
admin levels regions 1-6" https://openstreetmap.org/changeset/4377 
but have carried on regardless.  Mappers have repeatedly asked you to 
use geographically smaller changesets 
https://openstreetmap.org/changeset/44078387**https://openstreetmap.org/changeset/44090685 
https://openstreetmap.org/changeset/44203236 and yet you continue 
regardless.


Either you're incompetent in the changes you're making or you're lying 
to us; in neither case should you be continuing to edit as you have been 
doing.


... The way to solve the quality of this data is to analyze it with 
the OSM+Wikidata tool I have built,
... or with something else that doesn't require OSM to be mechanically 
edited by you first.  As has already been said 

Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

2017-09-26 Thread Marc Gemis
On Wed, Sep 27, 2017 at 1:17 AM, Andy Townsend  wrote:
> That's simply rubbish.  Tags on an OSM object describe it in the real world.
> They should be verifiable.  Whether an OSM object has a wikidata tag on it
> is essentially irrelevant as far as OSM is concerned - it's just a primary
> key into an external database.  External data consumers might find the data
> in that database useful, but they can also get to it via wikipedia tags
> (which, being human-readable, are more likely to be maintained), so it's
> really not a big deal.


I hope everyone realizes that there are Wikidata items for which there
is no Wikipedia article. So you cannot always find it via Wikipedia
tags.

And at least JOSM shows a human readable name of a Wikidata item
besides the Q-number. I think iD does this as well.

m. (who manually adds Wikidata references for Flemish churches after
creating the Wikidata items).

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


Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

2017-09-26 Thread Yuri Astrakhan
Yves, yes, they are external IDs. But so are wikipedia titles.  Visually
inspecting Wikipedia tile does not provide you with any way to verify its
correctness - you have to look in the external data source (WP).  As for
entering by hand - just like you shouldn't enter Wikipedia articles by hand
- you should copy/paste it from the article, or use the autocomplete field
in iD.  So in reality, these two things are nearly the same.  On the other
hand, modern rely on the internet connection, which means that an ID can be
shown as text in the user's language, together with other metadata from
Wikidata.  The concept of "internal" vs "external" is not as relevant now
as it was in the past...  (there is only one data - the internet :))

On Tue, Sep 26, 2017 at 1:43 PM, Yves  wrote:

> I think that the underlying issue in wikidata tags is that they are
> external IDs. Not human readable, they cannot be entered 'by hand' nor
> verified on the ground.
> Once you accept them in OSM, you can't really complain about bots.
>
> Yves (who still think such UIDs are only needed for the lack of good query
> tools).
>
>
>
> Le 26 septembre 2017 19:08:33 GMT+02:00, Yuri Astrakhan <
> yuriastrak...@gmail.com> a écrit :
>>
>> > p.s. OSM is a community project, not a programmers project, it's about
>>> > people, not software :-)
>>>
>>> It's both.  OSM is first and foremost is a community, but the result of
>> our effort is a machine-readable database.  We are not creating an
>> encyclopedia that will be casually flipped through by humans. We produce
>> data that gets interpreted by software, so that it can render maps and be
>> searchable.  For example, if every person uses their own tag names and ways
>> to record things, the data will have nearly zero value.  We must agree on
>> conventions so that software can understand our results - which is exactly
>> what we have been doing on wiki and in email channels. Any tag and value
>> that cannot be recognized and processed by software is effectively ignored.
>>
>>
>>>   Totally agree. If some script can automatically add new tag
>>> (wikidata) without any actual WORK needed, then it is pointless,
>>> anybody can run an auto-update script.
>>
>>   When ordinary (non geek) mappers do ACTUAL WORK - add wikipedia
>>> data, they add wikipedia link, not wikidata "stuff".
>>>
>>
>> While sand castles may look nice, they don't last very long. When
>> ordinary people add just the Wikipedia article, that link quickly gets
>> stale and become irrelevant and often incorrect. The wikipedia article
>> titles are not stable. They get renamed all the time - there are tens of
>> thousands of them in OSM already that I found.  Often, community renames wp
>> articles because there are more than one meaning, so they create a new
>> article with the same name in its place - a disambig page.  There is no
>> easy way to analyse wikipedia links for content - you cannot easily
>> determine if the wikipedia article is about a person, a country, or a
>> house, which makes it impossible to check for correctness.
>>
>> When I spend half an hour of my time researching which WP article is best
>> for an object, I do not want that effort to be wasted just because someone
>> else puts a disambig page in its place, and I have to redo all my work.
>>
>>   When data consumers want to get a link to corresponding wikipedia
>>> article, doing that with wikipedia[:xx] tags is straightforward. Doing
>>> the same with wikidata requires additional pointless and time
>>> consuming abrakadabra.
>>>
>>
>> no, you clearly haven't worked with any data consumers recently. Data
>> consumers want Wikidata, much more than wikipedia tags - please talk to
>> them. Wikidata gives you the list of wikipedia articles in all available
>> languages, it lets you get multi-lingual names when they are not specified
>> in OSM, it allows much more intelligent searches based on types of objects,
>> it allows quality controls.  The abrakadabra is exactly what one has to do
>> when parsing non-standardized data.
>>
>>>
>>>   Validation of wikipedia tag values can and IS already done using osm
>>> data versus wikipedia-geolocated data extracts/dumps.
>>>
>>> Sure, it can be via dump parsing, but it is a much more complicated than
>> querying.  Would you rather use Overpass turbo to do a quick search for
>> some weird thing that you noticed, or download and parse the dump?  Most
>> people would rather do the former. Here is the same thing - you *could* do
>> validation via a dump, but that barrier of entry is so high, most people
>> wouldn't.  With the new OSM+Wikidata tool, which is already getting
>> hundreds of thousands requests (!!!) , it is possible to get just the data
>> you need, and fix the problems that have been always present, but hidden.
>> And all that is possible because of a single tag.
>>
>
___
talk mailing list
talk@openstreetmap.org

Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

2017-09-26 Thread Yuri Astrakhan
>
> > p.s. OSM is a community project, not a programmers project, it's about
> > people, not software :-)
>
> It's both.  OSM is first and foremost is a community, but the result of
our effort is a machine-readable database.  We are not creating an
encyclopedia that will be casually flipped through by humans. We produce
data that gets interpreted by software, so that it can render maps and be
searchable.  For example, if every person uses their own tag names and ways
to record things, the data will have nearly zero value.  We must agree on
conventions so that software can understand our results - which is exactly
what we have been doing on wiki and in email channels. Any tag and value
that cannot be recognized and processed by software is effectively ignored.


>   Totally agree. If some script can automatically add new tag
> (wikidata) without any actual WORK needed, then it is pointless,
> anybody can run an auto-update script.

  When ordinary (non geek) mappers do ACTUAL WORK - add wikipedia
> data, they add wikipedia link, not wikidata "stuff".
>

While sand castles may look nice, they don't last very long. When ordinary
people add just the Wikipedia article, that link quickly gets stale and
become irrelevant and often incorrect. The wikipedia article titles are not
stable. They get renamed all the time - there are tens of thousands of them
in OSM already that I found.  Often, community renames wp articles because
there are more than one meaning, so they create a new article with the same
name in its place - a disambig page.  There is no easy way to analyse
wikipedia links for content - you cannot easily determine if the wikipedia
article is about a person, a country, or a house, which makes it impossible
to check for correctness.

When I spend half an hour of my time researching which WP article is best
for an object, I do not want that effort to be wasted just because someone
else puts a disambig page in its place, and I have to redo all my work.

  When data consumers want to get a link to corresponding wikipedia
> article, doing that with wikipedia[:xx] tags is straightforward. Doing
> the same with wikidata requires additional pointless and time
> consuming abrakadabra.
>

no, you clearly haven't worked with any data consumers recently. Data
consumers want Wikidata, much more than wikipedia tags - please talk to
them. Wikidata gives you the list of wikipedia articles in all available
languages, it lets you get multi-lingual names when they are not specified
in OSM, it allows much more intelligent searches based on types of objects,
it allows quality controls.  The abrakadabra is exactly what one has to do
when parsing non-standardized data.

>
>   Validation of wikipedia tag values can and IS already done using osm
> data versus wikipedia-geolocated data extracts/dumps.
>
> Sure, it can be via dump parsing, but it is a much more complicated than
querying.  Would you rather use Overpass turbo to do a quick search for
some weird thing that you noticed, or download and parse the dump?  Most
people would rather do the former. Here is the same thing - you *could* do
validation via a dump, but that barrier of entry is so high, most people
wouldn't.  With the new OSM+Wikidata tool, which is already getting
hundreds of thousands requests (!!!) , it is possible to get just the data
you need, and fix the problems that have been always present, but hidden.
And all that is possible because of a single tag.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

2017-09-26 Thread Yves
I think that the underlying issue in wikidata tags is that they are external 
IDs. Not human readable, they cannot be entered 'by hand' nor verified on the 
ground. 
Once you accept them in OSM, you can't really complain about bots. 

Yves (who still think such UIDs are only needed for the lack of good query 
tools).


Le 26 septembre 2017 19:08:33 GMT+02:00, Yuri Astrakhan 
 a écrit :
>>
>> > p.s. OSM is a community project, not a programmers project, it's
>about
>> > people, not software :-)
>>
>> It's both.  OSM is first and foremost is a community, but the result
>of
>our effort is a machine-readable database.  We are not creating an
>encyclopedia that will be casually flipped through by humans. We
>produce
>data that gets interpreted by software, so that it can render maps and
>be
>searchable.  For example, if every person uses their own tag names and
>ways
>to record things, the data will have nearly zero value.  We must agree
>on
>conventions so that software can understand our results - which is
>exactly
>what we have been doing on wiki and in email channels. Any tag and
>value
>that cannot be recognized and processed by software is effectively
>ignored.
>
>
>>   Totally agree. If some script can automatically add new tag
>> (wikidata) without any actual WORK needed, then it is pointless,
>> anybody can run an auto-update script.
>
>  When ordinary (non geek) mappers do ACTUAL WORK - add wikipedia
>> data, they add wikipedia link, not wikidata "stuff".
>>
>
>While sand castles may look nice, they don't last very long. When
>ordinary
>people add just the Wikipedia article, that link quickly gets stale and
>become irrelevant and often incorrect. The wikipedia article titles are
>not
>stable. They get renamed all the time - there are tens of thousands of
>them
>in OSM already that I found.  Often, community renames wp articles
>because
>there are more than one meaning, so they create a new article with the
>same
>name in its place - a disambig page.  There is no easy way to analyse
>wikipedia links for content - you cannot easily determine if the
>wikipedia
>article is about a person, a country, or a house, which makes it
>impossible
>to check for correctness.
>
>When I spend half an hour of my time researching which WP article is
>best
>for an object, I do not want that effort to be wasted just because
>someone
>else puts a disambig page in its place, and I have to redo all my work.
>
>  When data consumers want to get a link to corresponding wikipedia
>> article, doing that with wikipedia[:xx] tags is straightforward.
>Doing
>> the same with wikidata requires additional pointless and time
>> consuming abrakadabra.
>>
>
>no, you clearly haven't worked with any data consumers recently. Data
>consumers want Wikidata, much more than wikipedia tags - please talk to
>them. Wikidata gives you the list of wikipedia articles in all
>available
>languages, it lets you get multi-lingual names when they are not
>specified
>in OSM, it allows much more intelligent searches based on types of
>objects,
>it allows quality controls.  The abrakadabra is exactly what one has to
>do
>when parsing non-standardized data.
>
>>
>>   Validation of wikipedia tag values can and IS already done using
>osm
>> data versus wikipedia-geolocated data extracts/dumps.
>>
>> Sure, it can be via dump parsing, but it is a much more complicated
>than
>querying.  Would you rather use Overpass turbo to do a quick search for
>some weird thing that you noticed, or download and parse the dump? 
>Most
>people would rather do the former. Here is the same thing - you *could*
>do
>validation via a dump, but that barrier of entry is so high, most
>people
>wouldn't.  With the new OSM+Wikidata tool, which is already getting
>hundreds of thousands requests (!!!) , it is possible to get just the
>data
>you need, and fix the problems that have been always present, but
>hidden.
>And all that is possible because of a single tag.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [Talk-it] Chiusura fontanelle a Roma

2017-09-26 Thread Fabrizio
C'è già una mappatura in corso di quelle chiuse
http://www.reter.org/blog/index.php/notizie/reter-news/59-closed-fontanelle-i-nasoni-a-secco-nasonydry
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


[Talk-it] Aiuto su conditional restrictions

2017-09-26 Thread Marcello
Salve,

i comuni certo non facilitano la vita ai mappatori e non amano la
semplificazione, ad esempio volevo inserire le restrizioni di accesso
secondo la segnaletica della foto [1].

Al momento ho inserito:
access=private
disabled=yes
emergency=yes
foot=yes
goods=delivery

Vorrei aggiungere anche access:conditional=yes in base agli orari,
giorni della settimana e mesi, ma sono talmente tante le condizioni che
mi sto intrecciando sempre più e non ne esco. Qualcuno ha dei suggerimenti?

Grazie a tutti

[1] https://www.dropbox.com/s/a26h145wdkw7nn6/20170920_102002.jpg?dl=0

-- 
Ciao
Marcello


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


Re: [Talk-it] Sito statistiche "Dapal"

2017-09-26 Thread Federico Cortese
On Tue, Sep 26, 2017 at 10:30 AM, Andreas Lattmann
 wrote:
> Risposta secca: si!
> Perché è troppo bello. :-)

Mi aggiungo ai +1

Ciao,
Federico

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


Re: [Talk-it] Sito statistiche "Dapal"

2017-09-26 Thread Carlo Stemberger
Il grande dapal!

http://www.openstreetmap.org/user/David%20Paleino/history

Ultima modifica 3 anni fa 

+1 anche per me!

Carlo
-- 
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] Label language on the Default stylesheet

2017-09-26 Thread Imre Samu
>That sounds like an argument against any incremental improvement ever

imho: the risk Identification is an important design step.  [
https://en.wikipedia.org/wiki/Risk_management ]
And reducing risks is another step.



2017-09-25 16:34 GMT+02:00 Nicolás Alvarez :

>
> El 25 sept 2017, a las 10:54, Imre Samu  escribió:.
>
>
> What about the other alternatives?
>
> for example:
> - just adding ALL (official[1])  dual languages for only Z0-Z8 level, and
> keeping the current design for Z9-Z19
>
> so there will be  (z0-z8)
> - local + english
> - local + chinese
> - local + arabic
> - local + japanese
> - local + russian
> - local + german
> - local + spanish
> - ...
> - local + greek
> - local + hungarian
> - local + 
> - .
>
>
> This is 262144 more tiles *per language*. Who wants to donate a few disks?
>
>
> And the other question:   Adding the English language now  - can be
> counterproductive for implementing the full multi-language support?   (
> for example - less urgency?)
>
>
> That sounds like an argument against any incremental improvement ever.
> Wouldn't your proposed multilingual tiles cause less urgency for vector
> tiles too?
>
> Imre
> /native Hungarian/
>
>
>
> 2017-09-25 13:48 GMT+02:00 Matthijs Melissen :
>
>> On 25 September 2017 at 13:21, Richard Fairhurst 
>> wrote:
>> > Frederik Ramm wrote:
>> >> I'd invest the available brainpower in steps needed to achieve
>> >> this goal, even if it's a year or two in the future.
>> >
>> > Which means vector tiles... which we should be looking at anyway.
>> >
>> > But that needs to be a separate project really, rather than a facet of
>> > openstreetmap-carto.
>>
>> Yes, to re-iterate: my question is about things we can do now. Vector
>> tiles are on the horizon, but are likely to take a year or more from
>> now. Changing some of the labels is something we could do with one
>> line of code and roll out tomorrow, if we wanted to.
>>
>> -- Matthijs
>>
>>
>>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [Talk-it] Sito statistiche "Dapal"

2017-09-26 Thread Simone Cortesi
+1

2017-09-26 11:13 GMT+02:00 Ivo Reano :

> >Risposta secca: si!
>
>> >Perché è troppo bello. :-)
>> >Andreas Lattmann
>>
> Sono daccordo! Sarebbe divertente.
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>


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


Re: [Talk-it] Sito statistiche "Dapal"

2017-09-26 Thread dd dd
+1 anche qui

m.

Il giorno 26 settembre 2017 14:17, Simone Cortesi  ha
scritto:

> +1
>
> 2017-09-26 11:13 GMT+02:00 Ivo Reano :
>
>> >Risposta secca: si!
>>
>>> >Perché è troppo bello. :-)
>>> >Andreas Lattmann
>>>
>> Sono daccordo! Sarebbe divertente.
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>>
>
>
> --
> -S
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>


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


Re: [Talk-it] Sito statistiche "Dapal"

2017-09-26 Thread Gianluca Boero

+1 anche per me


Il 26/09/2017 15:29, dd dd ha scritto:

+1 anche qui

m.

Il giorno 26 settembre 2017 14:17, Simone Cortesi > ha scritto:


+1

2017-09-26 11:13 GMT+02:00 Ivo Reano >:

>Risposta secca: si!

>Perché è troppo bello. :-)
>Andreas Lattmann

Sono daccordo! Sarebbe divertente.

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





-- 
-S


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





--
Michele Ferretti


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


--
Gianluca Boero

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


[OSM-talk] OSM stats update

2017-09-26 Thread Andy Robinson
FYI I updated some of the stats charts at
https://wiki.openstreetmap.org/wiki/Stats

Cheers
Andy (blackadder)


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


Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread Frederik Ramm
Hi,

On 26.09.2017 13:31, Safwat Halaby wrote:
> V3 was an automatic import for all nodes. it was made pretty quickly
> after v1 and v2

This whole import is a terrible mess:

https://www.openstreetmap.org/node/1802982151/history

It starts with the version 1 already being titled "attempt 3", then in
version 2 a "fixme = check/adjust position and/or merge with existing
stop if exists" is added which of course is another wording for "this
import should not have happened in the first place"! Later all name tags
were duplicated in name:he and the latest three versions are also some
form of automated doctoring.

A month ago you've removed the "fixme=..." from 30k nodes and replaced
it with a "gtfs:reviewed=no", creating yet another version of the whole
data set in our database. What makes you think that, after the "fixme"
tags have *not* been acted on since the original import 5 years ago,
changing this to "gtfs:reviewed=no" will suddenly have an effect?

Are all these automatic edits at least discussed on the Israeli mailing
list, or is this a free-for-all where anyone who knows how to write a
script runs over all bus stops in Israel again and again?

Bye
Frederik

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

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


Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread john whelan
I suggest pulling in the country file and if need be chop it up to load
into JOSM.  Load up the latest bus stops in a different layer then use the
todo plugin and go through them one at a time cleaning them up that way.

Note that the GTFS file bus stop location may not be accurate, some bus
stops are known to be 100 meters out, it depends on the provider.  If you
have a system that announces bus stops for partially sighted people then
that is an indication they should be fairly good but check with the
provider.  Even when they are accurate they can still be out by a few
meters, locally one was in the middle of a road junction so they do need
verifying.

Cheerio John

On 26 September 2017 at 08:12, Frederik Ramm  wrote:

> Hi,
>
> On 26.09.2017 13:31, Safwat Halaby wrote:
> > V3 was an automatic import for all nodes. it was made pretty quickly
> > after v1 and v2
>
> This whole import is a terrible mess:
>
> https://www.openstreetmap.org/node/1802982151/history
>
> It starts with the version 1 already being titled "attempt 3", then in
> version 2 a "fixme = check/adjust position and/or merge with existing
> stop if exists" is added which of course is another wording for "this
> import should not have happened in the first place"! Later all name tags
> were duplicated in name:he and the latest three versions are also some
> form of automated doctoring.
>
> A month ago you've removed the "fixme=..." from 30k nodes and replaced
> it with a "gtfs:reviewed=no", creating yet another version of the whole
> data set in our database. What makes you think that, after the "fixme"
> tags have *not* been acted on since the original import 5 years ago,
> changing this to "gtfs:reviewed=no" will suddenly have an effect?
>
> Are all these automatic edits at least discussed on the Israeli mailing
> list, or is this a free-for-all where anyone who knows how to write a
> script runs over all bus stops in Israel again and again?
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Fixing OSM wikipedia redirects

2017-09-26 Thread Sarah Hoffmann
On Tue, Sep 26, 2017 at 04:03:35AM -0400, Yuri Astrakhan wrote:
> Sarah, my understanding is that MapRoulette does not support it -- I cannot
> upload the following:
> 
> For Object ID ,  change one set of tags for another -- accept or
> decline?

No you can't and you shouldn't. Clicking through to two websites and
copying the link is absolutely ok.

> Yes, the community can do it, the question is - should it?  Given 2
> challenges, one that requires some thought, and the other that require
> clicking yes without thinking, shouldn't we opt to the one that computers
> cannot do?  

That's exactly what I'm saying. People don't always want to do the
complicated tasks. There is enough in that in the day job. Sometimes
just clicking through a pile of wikipedia links is totally enough.

Don't just leave the complicated, messy parts of your scripts to the
mappers. It tends to be demotivating because there is no real progress
if you always have to do a lot of research for each single item. And
it is especially demotivating when it is the result of an automated
edit because it feels like spending your time to clean up other people's
mess.

We've just cleaned up hundereds of thousands of polygons through
Maproulette tasks. The popular challenges were the ones which were it
was clear what was to do (not necessarily the same as fixing was easy,
there were complicated multipolygon relations involved), not the ones
where you had to carefully analyse the map to understand what is
going on.

Sarah

> We seemed to assume that donated time is free, unlimited, and
> has very little value. I feel we should treat donated time as the most
> precious and most scarce resource we could get.
> 
> On Tue, Sep 26, 2017 at 3:48 AM, Sarah Hoffmann  wrote:
> 
> > On Mon, Sep 25, 2017 at 11:53:03PM -0400, Yuri Astrakhan wrote:
> > > According to Martijn (of MapRoulette fame), there is no way a challenge
> > can
> > > link to object IDs. MapRoulette can only highlight location. Nor can I
> > > provide a proposed fix, which means someone would have to manually find
> > the
> > > broken object, navigate to Wikipedia, copy/paste the title, and save the
> > > object.  I guesstimate 1 minute per object on average... that's nearly
> > 700
> > > hours of community time - a huge waste of human brain power that could be
> > > spent on a much more challenging and less automatable tasks.
> >
> > We'd have 40.000 more recently reviewed objects in the database. Given how
> > much the quality of the OSM data decays with time, I would consider that
> > a welcome boost to overall quality.
> >
> > And my experience with the OSM community is that there are a lot of people
> > who wouldn't consider such a task a waste of time but as a wonderful
> > opportunity to relax in the evening. Maproulette has the advantage that
> > you can just click away and do one object after the next. I would recommend
> > to break the 40.000 objects into local batches of 1000 or 2000 and just
> > load it into Maproulette. Add step-by-step isntructions how to fix the
> > links and I'm sure you'll be surprised how quickly everything is done.
> >
> > Kind regards
> >
> > Sarah
> >
> > >
> > > Osmose might be a good alternative, and might even lower the total number
> > > of hours required, but still - would that significantly benefit the
> > > project?  These tags are just a tiny arbitrary subset of one million
> > > wikipedia-tagged objects.  Verifying just them by hand seems like a waste
> > > of human intelligence. Instead, we can run queries to produce knowingly
> > bad
> > > objects and let community fix those. I hope we can let machines do
> > mindless
> > > tasks, and let humans do decision making.  This would improve
> > contributors
> > > morale, instead of making them feel like robots :)
> > >
> > > Clarifying: the OSM objects already point to those pages via redirect.
> > The
> > > redirect information is only stored in Wikipedia.
> > >
> > > On Mon, Sep 25, 2017 at 11:18 PM, Marc Gemis 
> > wrote:
> > >
> > > > or via Osmose ?
> > > >
> > > > On Tue, Sep 26, 2017 at 5:16 AM, Marc Gemis 
> > wrote:
> > > > > what about a Maproulette task ?
> > > > >
> > > > > On Tue, Sep 26, 2017 at 5:11 AM, Yuri Astrakhan <
> > yuriastrak...@gmail.com>
> > > > wrote:
> > > > >> At the moment, there are nearly 40,000 OSM objects whose wikipedia
> > tag
> > > > does
> > > > >> not match their wikidata tag. Most of them are Wikipedia redirects,
> > > > whose
> > > > >> target is the right wikipedia article. If we are not ready to
> > abandon
> > > > >> wikipedia tags just yet (I don't think we should ATM), I think we
> > > > should fix
> > > > >> them.  Fixing them by hand seems like a huge waste of the community
> > > > time,
> > > > >> when it can be semi-automated.
> > > > >>
> > > > >> I propose that a small program, possibly a plugin to JOSM, would
> > change
> > > > >> wikipedia tags to point to the target article 

Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

2017-09-26 Thread Christoph Hormann
On Tuesday 26 September 2017, Yuri Astrakhan wrote:
> Since this thread had not received any new discussion in the past 4
> days, I assumed all points were answered and proceeded as planned,
> per mechanical edit policy.

That is always a bad idea.  For example in this thread i made the 
following comment:

> > Christoph, a valid point. Yet the duplicate would allow finding
> > many of these errors, rather than leaving wp-only to go bad due to
> > changing nature of the WP articles.
>
> Actually no - you can find the errors just as well without adding the
> wikidata tags to OSM as after doing so.

You did not react to that so why would it make sense for you to assume 
this issue has been resolved - just by ignoring it?

> Per previous description, the existing data is already bad, and I am
> simply making it possible to identify it, after discussing it on this
> thread.

Sorry but this is utter nonsense.  Importing data into OSM is never 
required for either fixing errors in OSM or in the imported data.  If 
you do an import you need to make sure the results are at least on the 
same level of quality as they would be based on competent manual 
mapping.  You need to ensure that in data preparation and not after 
doing the import.

And the presence of pre-existing bad data (to a significant part already 
produced through under-the-radar mechanical edits by the way) is no 
excuse for adding more bad data.

> Andy, Wikidata ID is not correct or incorrect -- [...]

Then it is non-verifiable data and does not belong in the OSM database 
at all.

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

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


Re: [Talk-it] Domanda da nuovo arrivato!

2017-09-26 Thread Cascafico Giovanni
Il 26 settembre 2017 09:33, Gian Luca Gaiba
 ha scritto:


> 1) se volessi includere (o fare altra query) per le fermate degli autobus che 
> tags dovrei usare?

Guarda questa query [1] per le fermate di Udine

> 2) Se volessi avere i dati direttamente in csv e’ possibile?

Ti avevo già mandato il link per produrre direttamente un csv. In ogni
caso questo comando [2], derivato direttamente dalla query [1], ti
produce i dati; cerca e sostituisci "Udine" con altra città e riprova
a dare il comando...

> 3) Se replicassi questi dati in un mio database ogni quanto mi consigliate di 
> aggiornare/sincronizzare le tabelle?

Dipende dallo stato della mappa, dall'attività dei mappatori, dalle
variazione dell'azienda dei trasporti. Per Udine, dubito ci saranno
attività prossimamente, in quanto un utente ha già mappato tutto in
dettaglio. Nessuno ti vieta di mettere in crontab il comando [2] a tuo
piacimento :-)



[1] http://overpass-turbo.eu/s/rYt
[2] 
http://overpass-api.de/api/interpreter?data=%5Bout%3Acsv%28%3A%3Aid%2C%22name%22%2C%3A%3Alat%2C%3A%3Alon%3Btrue%3B%22%2C%22%29%5D%3Barea%5B%22name%22%3D%22Udine%22%5D%2D%3E%2Ea%3B%28node%28area%2Ea%29%5B%22highway%22%3D%22bus%5Fstop%22%5D%3B%29%3Bout%3B%0A

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


Re: [Talk-it] Sito statistiche "Dapal"

2017-09-26 Thread Ivo Reano
>Risposta secca: si!

> >Perché è troppo bello. :-)
> >Andreas Lattmann
>
Sono daccordo! Sarebbe divertente.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [OSM-talk] Fixing OSM wikipedia redirects

2017-09-26 Thread Mark Wagner
On Mon, 25 Sep 2017 23:11:52 -0400
Yuri Astrakhan  wrote:

> At the moment, there are nearly 40,000 OSM objects whose wikipedia
> tag does not match their wikidata tag. Most of them are Wikipedia
> redirects, whose target is the right wikipedia article.

What about the ones where the article is a Wikipedia redirect, whose
target is *almost, but not quite* the right Wikipedia article?  I'm
thinking about things like neighborhoods of a city, where Wikipedia
currently has a redirect to the city article.

-- 
Mark

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


Re: [Talk-it] Domanda da nuovo arrivato!

2017-09-26 Thread Gian Luca Gaiba
Perfetto!!!

funziona perfettamente 

grazie infinite a tutti!!!


Ultime 2 domande:
1) se volessi includere (o fare altra query)
per le fermate degli autobus
che tags dovrei usare?

2) Se volessi avere i dati direttamente in csv e’ possibile?

3) Se replicassi questi dati in un mio database
ogni quanto mi consigliate di aggiornare/sincronizzare le tabelle?

grazie ancora
e scusate il tempo che ci ho messo a rispondere ma mi son voluto un po’ 
studiare la query…

cia

> On 21 Sep 2017, at 22:46, Andrea Albani  wrote:
> 
> Ciao,
> 
> se per stazioni intendi anche le c.d. fermate, ovvero quelle situate su linee 
> minori tipicamente senza presidio, allora devi ricercare anche il tag 
> railway=halt (vedi [0]).  Puoi usare la query che ti ha già indicato Cesare 
> Gerbino modificandola come segue:
> 
> [out:json][timeout:250];
> // fetch area “Italia” to search in
> {{geocodeArea:Italia}}->.searchArea;
> // gather results
> (
>   node["railway"="station"](area.searchArea);
>   node["railway"="halt"](area.searchArea);
> );
> // print results
> out body;
> >;
> out skel qt;
> 
> Ciao
> 
> [0] http://wiki.openstreetmap.org/wiki/Tag:railway%3Dhalt 
> 
> ___
> 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] Adding wikidata tags to the remaining objects with only wikipedia tag

2017-09-26 Thread Andy Mabbett
On 26 September 2017 at 03:40, Yuri Astrakhan  wrote:

> I have been blocked by Andy Townsend with the following message.
> I believe Andy is acting in best interest of the project, yet might have
> missed or misread this discussion.

I agree with Yuri.

This series of edits will, once complete, leave OSM in a much better
state than before; with invalid or outdated Wikipedia tags identified
and replaced (or removed); with the bonus of good Wikidata tags added
to them.

Yuri should be unblocked, and allowed to complete the job.

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


Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

2017-09-26 Thread Andy Mabbett
On 26 September 2017 at 04:14, Marc Gemis  wrote:

> I believe the mechanical edit polity demands that you discuss with the
> *local* community. That means if your edit modifies items in e.g.
> Mexico, Belgium and Japan, you have to discuss your edit with the
> communities in Mexico, Belgium and Japan.

That is clearly impractical for a task of this nature and, if true,
would be an effective prohibition on any such beneficial editing.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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


Re: [Talk-it] Sito statistiche "Dapal"

2017-09-26 Thread Andreas Lattmann
Risposta secca: si!
Perché è troppo bello. :-)
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] Adding wikidata tags to the remaining objects with only wikipedia tag

2017-09-26 Thread Marc Gemis
Seems, that I was mistaken:

https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct states:

Either talk (a general purpose mailing list)
or if your edit affects only one country or territory then the
national-language mailing lists, forums, or other standard
communication methods for the territory affected by the change
or ...


This seems odd to me, as not all communities affected by a mechanical
edit are represented in talk. So this means that the country in which
most edits will take place do not have to be consulted ?

regards

m.

p.s. OSM is a community project, not a programmers project, it's about
people, not software :-)

On Tue, Sep 26, 2017 at 10:02 AM, Andy Mabbett
 wrote:
> On 26 September 2017 at 04:14, Marc Gemis  wrote:
>
>> I believe the mechanical edit polity demands that you discuss with the
>> *local* community. That means if your edit modifies items in e.g.
>> Mexico, Belgium and Japan, you have to discuss your edit with the
>> communities in Mexico, Belgium and Japan.
>
> That is clearly impractical for a task of this nature and, if true,
> would be an effective prohibition on any such beneficial editing.
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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


Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread Michael Reichert
Hi,

Am 2017-09-26 um 09:19 schrieb SwiftFast:
> I need to download all version 3 bus stops in a country which has about
> 30,000 bus stops. Version 3 exists since a 2012 import. What's the
> recommended way to accomplish this? I have two ways in mind.

Version 3 of what?

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


[Talk-it] Sito statistiche "Dapal"

2017-09-26 Thread Fabrizio Tambussa
Mi pacerebbe far risorgere un clone del vecchio sito di statistiche a
suo tempo curato da David "Dapal" Paleino, di cui una copia superstite
è visibile qui [-1].
Per chi non lo avesse mai frequentato (stiamo parlando di 6 o 7 anni
fa) il sito pubblicava la classifica degli oggetti più mappati
suddivisi per ogni mappatore, aggiornata settimanalmente.
Venivano conteggiati solo i nuovi inserimenti, non le modifiche.
Ad esempio simone aveva mappato in totale 4516964 nodi. Scegliendo la
categoria "amenity, si vede che Ale_zena_IT aveva mappato in totale
171 oggetti amenity=bank, ecc ecc.

Domanda secca: c'è ancora bisogno di uno strumento simile?

Saluti

Sbiribizio

[-1] 
https://web.archive.org/web/20101014112121/http://osmstats.hanskalabs.net:80/stats/

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


Re: [Talk-it] Metro Roma

2017-09-26 Thread Dino Michelini
  

Ciao, ho fatto una verifica. Per il tratto urbano della FL3 ed è
tutto ok; tunnel=yes è già presente nelle stazioni sotterranee. Le
stazioni della "linea A"
(https://it.wikipedia.org/wiki/Linea_A_(metropolitana_di_Roma) [5]) sono
sotterranee mentre sulla "linea B"
(https://it.wikipedia.org/wiki/Linea_B_(metropolitana_di_Roma) [6]) la
situazione è più articolata: le stazioni comprese nel tratto Piramide -
Eur Magliana sono in superficie (livello 1 dal piano stradale ad
eccezione di Piramide che è sotto il piano stradale ma non è sotterranea
ma senza galleria/tunnel). 

Dino 

Il 25.09.2017 15:39 Martin
Koppenhoefer ha scritto: 

> sent from a phone
> 
>> On 25. Sep 2017, at
15:31, Dino Michelini wrote: Diao, alcune stazioni ferroviarie della FL3
tratta Cesano-Roma Ostiense (non svolge servizio di metropolitana
https://it.wikipedia.org/wiki/Servizi_ferroviari_suburbani_di_Roma#Linea_FL3
[2]) sono in superficie (Cesano-Olgiata-la
Storta-Giustignana-Ottavia-Ipogeo degli Ottavi-S. Filippo Neri-Monte
Mario-Valle Aurelia [elevata su ponte]) altre sotterranee
(Gemelli-Balduina-Appiano-Quattro Venti)
> 
> a quelli sotterranee va
aggiunto tunnel=yes, o cosa intendi?
> 
> Ciao, Martin 
>
___
> Talk-it mailing list
>
Talk-it@openstreetmap.org [3]
>
https://lists.openstreetmap.org/listinfo/talk-it [4]
 



Con Mobile Open 7 GB a 9 euro/4 sett navighi veloce con 7 GB di Internet e hai 
200 minuti ed SMS a 15 cent. Passa a Tiscali Mobile! http://tisca.li/Open7GB0617

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


[OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread SwiftFast
I need to download all version 3 bus stops in a country which has about
30,000 bus stops. Version 3 exists since a 2012 import. What's the
recommended way to accomplish this? I have two ways in mind.

1. Fetch all stops with Overpass API, then, for each
   stop id, fetch version 3 from the main API.
   - Pros: I already know how to do that
   - Cons: Potentially too much load on the OSM server.
   Will I be rate-limited?
   Requires some script writing which could take
   more time than the way below.

2. Download a history-supporting planet file, 
   and extract the desired bus stops through Osmosis.
   - Pros: Less API load
   - Cons: I'm not sure what the proper Osmosis commands are,
   and if this  is a supported operation. Also, I need
   to download a big file (the oldest history supporting
   import is 40GB from 2013).

3. Other suggestions?

Why I need this:

I am creating a script[1] for incrementally updating GTFS imports.
It'll initially be used in Israel but it can be adopted worldwide. We
have an import from 2012 which was "dumped and forgotten" and is now
very stale. I want to forever fix this. 

The ministry of transportation publishes new GTFS files daily. My
script compares an older GTFS file with newer one, and only updates the
bus stops that were changed/added/deleted. The idea is to feed it a 
newer GTFS database daily or weekly. However, I do not possess the file
that was used in the 2012 import, so, in order to bootstrap the script,
I need to recreate that file from the old OSM data.

[1] https://forum.openstreetmap.org/viewtopic.php?id=16738=3 
(note: SwiftFast and SafwatHalaby are both me)

Thanks in advance.

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


Re: [OSM-talk] Fixing OSM wikipedia redirects

2017-09-26 Thread Yuri Astrakhan
Sarah, my understanding is that MapRoulette does not support it -- I cannot
upload the following:

For Object ID ,  change one set of tags for another -- accept or
decline?

Would be great if I was wrong.

Yes, the community can do it, the question is - should it?  Given 2
challenges, one that requires some thought, and the other that require
clicking yes without thinking, shouldn't we opt to the one that computers
cannot do?  We seemed to assume that donated time is free, unlimited, and
has very little value. I feel we should treat donated time as the most
precious and most scarce resource we could get.

On Tue, Sep 26, 2017 at 3:48 AM, Sarah Hoffmann  wrote:

> On Mon, Sep 25, 2017 at 11:53:03PM -0400, Yuri Astrakhan wrote:
> > According to Martijn (of MapRoulette fame), there is no way a challenge
> can
> > link to object IDs. MapRoulette can only highlight location. Nor can I
> > provide a proposed fix, which means someone would have to manually find
> the
> > broken object, navigate to Wikipedia, copy/paste the title, and save the
> > object.  I guesstimate 1 minute per object on average... that's nearly
> 700
> > hours of community time - a huge waste of human brain power that could be
> > spent on a much more challenging and less automatable tasks.
>
> We'd have 40.000 more recently reviewed objects in the database. Given how
> much the quality of the OSM data decays with time, I would consider that
> a welcome boost to overall quality.
>
> And my experience with the OSM community is that there are a lot of people
> who wouldn't consider such a task a waste of time but as a wonderful
> opportunity to relax in the evening. Maproulette has the advantage that
> you can just click away and do one object after the next. I would recommend
> to break the 40.000 objects into local batches of 1000 or 2000 and just
> load it into Maproulette. Add step-by-step isntructions how to fix the
> links and I'm sure you'll be surprised how quickly everything is done.
>
> Kind regards
>
> Sarah
>
> >
> > Osmose might be a good alternative, and might even lower the total number
> > of hours required, but still - would that significantly benefit the
> > project?  These tags are just a tiny arbitrary subset of one million
> > wikipedia-tagged objects.  Verifying just them by hand seems like a waste
> > of human intelligence. Instead, we can run queries to produce knowingly
> bad
> > objects and let community fix those. I hope we can let machines do
> mindless
> > tasks, and let humans do decision making.  This would improve
> contributors
> > morale, instead of making them feel like robots :)
> >
> > Clarifying: the OSM objects already point to those pages via redirect.
> The
> > redirect information is only stored in Wikipedia.
> >
> > On Mon, Sep 25, 2017 at 11:18 PM, Marc Gemis 
> wrote:
> >
> > > or via Osmose ?
> > >
> > > On Tue, Sep 26, 2017 at 5:16 AM, Marc Gemis 
> wrote:
> > > > what about a Maproulette task ?
> > > >
> > > > On Tue, Sep 26, 2017 at 5:11 AM, Yuri Astrakhan <
> yuriastrak...@gmail.com>
> > > wrote:
> > > >> At the moment, there are nearly 40,000 OSM objects whose wikipedia
> tag
> > > does
> > > >> not match their wikidata tag. Most of them are Wikipedia redirects,
> > > whose
> > > >> target is the right wikipedia article. If we are not ready to
> abandon
> > > >> wikipedia tags just yet (I don't think we should ATM), I think we
> > > should fix
> > > >> them.  Fixing them by hand seems like a huge waste of the community
> > > time,
> > > >> when it can be semi-automated.
> > > >>
> > > >> I propose that a small program, possibly a plugin to JOSM, would
> change
> > > >> wikipedia tags to point to the target article instead of the
> redirect.
> > > >>
> > > >> Thoughts?
> > > >>
> > > >> ___
> > > >> talk mailing list
> > > >> talk@openstreetmap.org
> > > >> https://lists.openstreetmap.org/listinfo/talk
> > > >>
> > >
>
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Fixing OSM wikipedia redirects

2017-09-26 Thread Yuri Astrakhan
Mark, these do rarely happen, but do they add value?  Having data that
points to a non-(machine)-verifiable redirect, a redirect that could be
deleted or changed at any moment is very fragile.

I think these should be resolved to the target, and treated as I described
in [1] - links to wikipedia pages about multiple objects.  This way it will
be clear that the tag points to a subsection/component of an article, and
will be treated accordingly.

[1]
https://wiki.openstreetmap.org/wiki/Wikipedia_Improvement_Tasks#Links_to_Wikipedia_pages_about_multiple_objects

On Tue, Sep 26, 2017 at 2:58 AM, Mark Wagner  wrote:

> On Mon, 25 Sep 2017 23:11:52 -0400
> Yuri Astrakhan  wrote:
>
> > At the moment, there are nearly 40,000 OSM objects whose wikipedia
> > tag does not match their wikidata tag. Most of them are Wikipedia
> > redirects, whose target is the right wikipedia article.
>
> What about the ones where the article is a Wikipedia redirect, whose
> target is *almost, but not quite* the right Wikipedia article?  I'm
> thinking about things like neighborhoods of a city, where Wikipedia
> currently has a redirect to the city article.
>
> --
> Mark
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Fixing OSM wikipedia redirects

2017-09-26 Thread Sarah Hoffmann
On Mon, Sep 25, 2017 at 11:53:03PM -0400, Yuri Astrakhan wrote:
> According to Martijn (of MapRoulette fame), there is no way a challenge can
> link to object IDs. MapRoulette can only highlight location. Nor can I
> provide a proposed fix, which means someone would have to manually find the
> broken object, navigate to Wikipedia, copy/paste the title, and save the
> object.  I guesstimate 1 minute per object on average... that's nearly 700
> hours of community time - a huge waste of human brain power that could be
> spent on a much more challenging and less automatable tasks.

We'd have 40.000 more recently reviewed objects in the database. Given how
much the quality of the OSM data decays with time, I would consider that
a welcome boost to overall quality.

And my experience with the OSM community is that there are a lot of people
who wouldn't consider such a task a waste of time but as a wonderful
opportunity to relax in the evening. Maproulette has the advantage that
you can just click away and do one object after the next. I would recommend
to break the 40.000 objects into local batches of 1000 or 2000 and just
load it into Maproulette. Add step-by-step isntructions how to fix the
links and I'm sure you'll be surprised how quickly everything is done.

Kind regards

Sarah

> 
> Osmose might be a good alternative, and might even lower the total number
> of hours required, but still - would that significantly benefit the
> project?  These tags are just a tiny arbitrary subset of one million
> wikipedia-tagged objects.  Verifying just them by hand seems like a waste
> of human intelligence. Instead, we can run queries to produce knowingly bad
> objects and let community fix those. I hope we can let machines do mindless
> tasks, and let humans do decision making.  This would improve contributors
> morale, instead of making them feel like robots :)
> 
> Clarifying: the OSM objects already point to those pages via redirect. The
> redirect information is only stored in Wikipedia.
> 
> On Mon, Sep 25, 2017 at 11:18 PM, Marc Gemis  wrote:
> 
> > or via Osmose ?
> >
> > On Tue, Sep 26, 2017 at 5:16 AM, Marc Gemis  wrote:
> > > what about a Maproulette task ?
> > >
> > > On Tue, Sep 26, 2017 at 5:11 AM, Yuri Astrakhan 
> > wrote:
> > >> At the moment, there are nearly 40,000 OSM objects whose wikipedia tag
> > does
> > >> not match their wikidata tag. Most of them are Wikipedia redirects,
> > whose
> > >> target is the right wikipedia article. If we are not ready to abandon
> > >> wikipedia tags just yet (I don't think we should ATM), I think we
> > should fix
> > >> them.  Fixing them by hand seems like a huge waste of the community
> > time,
> > >> when it can be semi-automated.
> > >>
> > >> I propose that a small program, possibly a plugin to JOSM, would change
> > >> wikipedia tags to point to the target article instead of the redirect.
> > >>
> > >> Thoughts?
> > >>
> > >> ___
> > >> talk mailing list
> > >> talk@openstreetmap.org
> > >> https://lists.openstreetmap.org/listinfo/talk
> > >>
> >

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


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


Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread Tom Hughes

On 26/09/17 11:41, Safwat Halaby wrote:

On Tue, 2017-09-26 at 11:31 +0200, Michael Reichert wrote:

Hi,

Am 2017-09-26 um 09:19 schrieb SwiftFast:

I need to download all version 3 bus stops in a country which has
about
30,000 bus stops. Version 3 exists since a 2012 import. What's the
recommended way to accomplish this? I have two ways in mind.


Version 3 of what?

Best regards



Version 3 of all Israeli bus stops that have "source=israel_gtfs_v1".
See this: https://www.openstreetmap.org/node/1802982884/history and
look at "version #3".


But how do you know it's version 3 you want for every one?

It sounds like you're making an assumption that all these objects have 
only been edited in a particular way by some automated process and that 
nobody has ever touched one by hand and hence added an extra version.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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


Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread Safwat Halaby
I think I've needlessly overcomplicated this. All I need to do was to
do is fetch changeset #14265835, which introduced those historic nodes.

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


Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread Jo
Hi Safwat,

Overpass API is definitely your friend. Version 3 doesn't mean much though.
Do you mean all bus stops with a public_transport tag?

I would go about it in a slightly different way and download everything
related to public transport, not just the stops using the query found on
this page:

https://wiki.openstreetmap.org/wiki/JOSM/Plugins/PT_Assistant/Mapping_Public_Transport_with_JOSM#Downloading_data

Then load that in PostGIS and create scripts to read GTFS into PostGIS.

Then compare the data in the DB and produce output and ideally a UI.

I started doing something like that here:

https://github.com/osmbe/public_transport

Let me know if you see ways of working on that or another way to tackle the
problem together.

Jo

2017-09-26 9:19 GMT+02:00 SwiftFast :

> I need to download all version 3 bus stops in a country which has about
> 30,000 bus stops. Version 3 exists since a 2012 import. What's the
> recommended way to accomplish this? I have two ways in mind.
>
> 1. Fetch all stops with Overpass API, then, for each
>stop id, fetch version 3 from the main API.
>- Pros: I already know how to do that
>- Cons: Potentially too much load on the OSM server.
>Will I be rate-limited?
>Requires some script writing which could take
>more time than the way below.
>
> 2. Download a history-supporting planet file,
>and extract the desired bus stops through Osmosis.
>- Pros: Less API load
>- Cons: I'm not sure what the proper Osmosis commands are,
>and if this  is a supported operation. Also, I need
>to download a big file (the oldest history supporting
>import is 40GB from 2013).
>
> 3. Other suggestions?
>
> Why I need this:
>
> I am creating a script[1] for incrementally updating GTFS imports.
> It'll initially be used in Israel but it can be adopted worldwide. We
> have an import from 2012 which was "dumped and forgotten" and is now
> very stale. I want to forever fix this.
>
> The ministry of transportation publishes new GTFS files daily. My
> script compares an older GTFS file with newer one, and only updates the
> bus stops that were changed/added/deleted. The idea is to feed it a
> newer GTFS database daily or weekly. However, I do not possess the file
> that was used in the 2012 import, so, in order to bootstrap the script,
> I need to recreate that file from the old OSM data.
>
> [1] https://forum.openstreetmap.org/viewtopic.php?id=16738=3
> (note: SwiftFast and SafwatHalaby are both me)
>
> Thanks in advance.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread Safwat Halaby
On Tue, 2017-09-26 at 11:31 +0200, Michael Reichert wrote:
> Hi,
> 
> Am 2017-09-26 um 09:19 schrieb SwiftFast:
> > I need to download all version 3 bus stops in a country which has
> > about
> > 30,000 bus stops. Version 3 exists since a 2012 import. What's the
> > recommended way to accomplish this? I have two ways in mind.
> 
> Version 3 of what?
> 
> Best regards
> 

Version 3 of all Israeli bus stops that have "source=israel_gtfs_v1".
See this: https://www.openstreetmap.org/node/1802982884/history and
look at "version #3".

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


Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

2017-09-26 Thread Tomas Straupis
> p.s. OSM is a community project, not a programmers project, it's about
> people, not software :-)

  Totally agree. If some script can automatically add new tag
(wikidata) without any actual WORK needed, then it is pointless,
anybody can run an auto-update script.

  When ordinary (non geek) mappers do ACTUAL WORK - add wikipedia
data, they add wikipedia link, not wikidata "stuff".

  When data consumers want to get a link to corresponding wikipedia
article, doing that with wikipedia[:xx] tags is straightforward. Doing
the same with wikidata requires additional pointless and time
consuming abrakadabra.

  Validation of wikipedia tag values can and IS already done using osm
data versus wikipedia-geolocated data extracts/dumps.

-- 
Tomas

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


Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread Safwat Halaby
On Tue, 2017-09-26 at 11:46 +0200, Jo wrote:
> Hi Safwat,
> 
> Overpass API is definitely your friend. Version 3 doesn't mean much
> though.
> Do you mean all bus stops with a public_transport tag?

Thanks for the reply.

By version 3, I mean a particular historic version of the OSM element. 

For instance, see "Version #3" of this bus stop:

https://www.openstreetmap.org/node/1802982884/history

I need all "version #3" of all bus stops that have a
"source=israel_gtfs_v1" in Israel. As far as I know. Overpass can only
fetch the latest version. Can overpass directly fetch version #3?

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


Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread Safwat Halaby
On Tue, 2017-09-26 at 12:15 +0100, Tom Hughes wrote:
> On 26/09/17 11:41, Safwat Halaby wrote:
> > On Tue, 2017-09-26 at 11:31 +0200, Michael Reichert wrote:
> > > Hi,
> > > 
> > > Am 2017-09-26 um 09:19 schrieb SwiftFast:
> > > > I need to download all version 3 bus stops in a country which
> > > > has
> > > > about
> > > > 30,000 bus stops. Version 3 exists since a 2012 import. What's
> > > > the
> > > > recommended way to accomplish this? I have two ways in mind.
> > > 
> > > Version 3 of what?
> > > 
> > > Best regards
> > > 
> > 
> > Version 3 of all Israeli bus stops that have
> > "source=israel_gtfs_v1".
> > See this: https://www.openstreetmap.org/node/1802982884/history and
> > look at "version #3".
> 
> But how do you know it's version 3 you want for every one?
> 
> It sounds like you're making an assumption that all these objects
> have 
> only been edited in a particular way by some automated process and
> that 
> nobody has ever touched one by hand and hence added an extra version.
> 
> Tom
> 

V3 was an automatic import for all nodes. it was made pretty quickly
after v1 and v2 and it's very unlikely someone edited during that time.
But I solved my problems simply by fetching the responsible changeset.
I was overcomplicating this problem. All I needed was:

get https://api.openstreetmap.org/api/0.6/changeset/14265835/download

Thanks for the help!

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


Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread Jo
It is a bit odd that you are not interested in the latest versions of these
objects, but OK. (As long as you don't plan to use them for an updated
import to OSM, of course)

Overpass API also makes it possible to fetch data for a given point in time.

Jo

2017-09-26 13:31 GMT+02:00 Safwat Halaby :

> On Tue, 2017-09-26 at 12:15 +0100, Tom Hughes wrote:
> > On 26/09/17 11:41, Safwat Halaby wrote:
> > > On Tue, 2017-09-26 at 11:31 +0200, Michael Reichert wrote:
> > > > Hi,
> > > >
> > > > Am 2017-09-26 um 09:19 schrieb SwiftFast:
> > > > > I need to download all version 3 bus stops in a country which
> > > > > has
> > > > > about
> > > > > 30,000 bus stops. Version 3 exists since a 2012 import. What's
> > > > > the
> > > > > recommended way to accomplish this? I have two ways in mind.
> > > >
> > > > Version 3 of what?
> > > >
> > > > Best regards
> > > >
> > >
> > > Version 3 of all Israeli bus stops that have
> > > "source=israel_gtfs_v1".
> > > See this: https://www.openstreetmap.org/node/1802982884/history and
> > > look at "version #3".
> >
> > But how do you know it's version 3 you want for every one?
> >
> > It sounds like you're making an assumption that all these objects
> > have
> > only been edited in a particular way by some automated process and
> > that
> > nobody has ever touched one by hand and hence added an extra version.
> >
> > Tom
> >
>
> V3 was an automatic import for all nodes. it was made pretty quickly
> after v1 and v2 and it's very unlikely someone edited during that time.
> But I solved my problems simply by fetching the responsible changeset.
> I was overcomplicating this problem. All I needed was:
>
> get https://api.openstreetmap.org/api/0.6/changeset/14265835/download
>
> Thanks for the help!
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Redacting 75, 000 street names contributed by user chdr

2017-09-26 Thread Martijn van Exel
Hi Frederik,
In your email from Aug 28 you proposed to wait a while as a first step to 
gather some feedback on your assessment. Did you receive any? When do you think 
you want to proceed with the redaction? Anything we can do to help?
I can assist with preparing the MapRoulette challenge to re-tag the redacted 
roads. We can take steps to ensure that people use legit sources: run a 
separate challenge for each region and point to specific sources that can be 
used for that region, for example. If you can shed some light on when you want 
to proceed, I can time that work accordingly.
Martijn

> On Sep 19, 2017, at 12:34 AM, Greg Morgan  wrote:
> 
> 
> 
> On Fri, Sep 8, 2017 at 3:48 AM, Bianca Hambasan  > wrote:
> Hi,
> 
>  
> 
> We, the map analysts team from Telenav started editing in Phoenix by adding 
> and reviewing the road geometry and road name, so we found this issue too. In 
> our area of interest, we found about 5 200 ways with this tag. We want to 
> help with this since we already edit in the area. Do you have any suggestions 
> if we can contribute without overlapping our work? We can also use Map 
> Roulette challenges, so anyone can be involved. If you have any other 
> suggestion, we are open to them.
> 
> As a source, we use Tiger data and Open Street Cam. What do you think about 
> the accuracy of them?
> 
>  
> 
> 
> Frederik,
> 
> What is the status of your name redaction?  chdr impacted many of the streets 
> that I made edits to.  I'd like to start fixing the names with the Tiger 2015 
> layer.  However, I need to wait on your redaction.  I marked the streets that 
> need to be attended to by the chdr_USA_AZ_name_fixup_required tag. I am not 
> sure if your redaction will remove my name tag target or not.  Can you 
> localize you redaction to just Arizona so that I can get going?  As noted by 
> Bianca, Telenav is in the area editing right now and would love to help with 
> the fix up effort.
> 
> Please Advise,
> Greg
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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


Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

2017-09-26 Thread Safwat Halaby
Hi John Whelan,

As implied in the forum thread, not wanting to destroy user data is
exactly why I'm building a relatively complex script. The naive
approach is to destroy all-bus stops are re-import, everytime a GTFS
update is released. But I don't want that.

Instead of doing that, the script preserves all user-submitted data
such as shelter, wheelchair, and GPS coordinate fixes and provides
incremental updates rather than the destruction of all bus stops per
import. The incremental updates do not destroy user changes. In order
to achieve that, the older and the newer GTFS database need to be
compared per update.

Yesterday I didn't have the database which was used in the old 2012
import, so I couldn't locally test-run my script. which is what lead to
my original question in this thread. But now I managed to reverse-build 
the old GTFS database from version 3 of the bus stops in Israel by
downloading the bus stops through the relevant changesets.

Here's some of the discussion:

>Here's a merging idea.
>
>Problem: Dealing with conflicts between mapper
edits and gtfs data.
>Solution: "The most recent version is the correct
version" philosophy.
>
>- The first gtfs update would update everything.
Conflicts are
>  resolved by prioritizing the gtfs file's version. This
is a
>  "necessary evil" but is >only needed once.  (edit: I might be
> 
able to mitigate this by tracing bus stop OSM history).
>- Some time
passes, and users update some of the bus stops.
>- The ministry of
transportation updates some bus stops in
>  its database and publishes a
new gtfs file.
>- The next gtfs update would inspect the difference
between
>  the new gtfs file and the older gtfs file. Only bus stops
> 
that have had their data (in >the gtfs file) changed since the
>  last
file are updated. So, conflicts are resolved by prioritizing
>  the gtfs
file version, but only for the bus stops that were changed
>  by the
ministry since the last update. The rest of the bus stops 
>  are left
intact.

(source: https://forum.openstreetmap.org/viewtopic.php?id=16738=3)

Also, we know the data can be used in OSM.

https://forum.openstreetmap.org/viewtopic.php?pid=244096#p244096

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


Re: [OSM-talk-fr] Présentation

2017-09-26 Thread gnrc
Bonjour Cédric, 

nous avons sur Lyon un groupe de contributeurs plutôt actif, qui se réuni tous 
les mois en toute convivialité à coté de la gare de la part-dieu, précisément 
au TUBA, les 2eme mardi. Nous serions ravi de t'y rencontrer. Voici quelques 
liens pour garder le contact : 

- Le wiki OSM, page Lyon 
https://wiki.openstreetmap.org/wiki/FR:Lyon 
et l'ordre du jour de notre prochaine rencontre 
https://wiki.openstreetmap.org/wiki/Lyon/Reunion_10_octobre_2017 

- La mailing-list lyonnaise accessible à tous en lecture, une simple demande 
d'accès te permettra de poster ou répondre aux sujets 
http://listes.openstreetmap.fr/wws/arc/local-lyon 

Un bon moyen de te former à JOSM serait de venir faire un missingmap, ou de 
venir à nos animations à la Maison des Rancy (proche métro saxe/Gambetta) sur 
JOSM/umap/overpass-turbo. 

Au plaisir de te rencontrer lors d'une de nos activités 
Christian (gnrc69) - chaque goutte rempli l’océan (du libre) 


- Mail original -

De: "Cédric Frayssinet"  
À: "Discussions sur OSM en français"  
Envoyé: Lundi 25 Septembre 2017 19:51:02 
Objet: [OSM-talk-fr] Présentation 



Bonjour à tous, 

Nouveau sur cette liste, je me présente rapidement. 

Je suis enseignant en Sciences de l'Ingénieur à Lyon, formateur académique au 
numérique et, on peut le dire, libriste... 

J'ai un compte OSM depuis 2011, mais je suis plus actif depuis quelques mois. 
J'ai commencé à cartographier avec précision mon village de vacances, puis, je 
suis tombé dans la marmite... bien aidé par les applications OSMand~, 
StreetComplete, OSMContributor et un peu OpenStreetCam. 


J'avoue, je n'utilise pas encore JOSM, seulement ID que je trouve parfait pour 
débuter. Mais je compte bien m'y mettre dès que je trouverai le temps de 
parcourir des tutos. 

Je me suis inscrit ici pour poser des questions de débutant, j'espère que c'est 
le lieu, car les derniers me font penser qu'il y a quelques experts dans la 
communauté, et c'est tant mieux ! 

Bonne soirée, 

Cédric 


-- 
En cure de désintoxication de Google ! Client d' Enercoop , l'énergie militante 


Également sur Mastodon : @bristow...@framapiaf.org 




___ 
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-dk] Standardisering af tankstationer i DK

2017-09-26 Thread Niels Elgaard Larsen


Michael Andersen:

> Der står faktisk Statoil på skiltet ved den station (se https://
> www.mapillary.com/map/im/ND1v2JKNGlQ30_iSVi4mTA) og lige nedenunder med en 
> anelse mindre bogstaver står der 1-2-3. 


Det har du da ret i. Jeg har aldrig lagt mærke til skiltet på
Vesterhavsvej, selvom det er stort.

Den i Brøns har til gengæld et rigtigt 1-2-3 skilt:

https://d1cuyjsrcm0gby.cloudfront.net/3mwT8HWnvQEXgVZNelmBxg/thumb-2048.jpg


i OSM har den name=1-2-3, operator=Statoil.

Hvilket jeg mener er korrekt, bortset fra at Statoil nu er Circle K.


> Jeg kommer jævnligt selv forbi, men må da indrømme at jeg har undret mig over 
> hvad der mon var det rette primære navn og har derfor efterfølgende ikke 
> rettet andre.

Og jeg synes at den på Rømø burde tagges på samme måde som den i Brøns,
selvom Statoil logoet godt nok er ret stort. For det er en 1-2-3
benzinstation. 1-2-3 er vel en slags discount Circle-K så bilister kan
foretrække 1-2-3 fremfor Circle-K eller foretrække Circle-K, hvis de vil
have betjening eller hotdogs.


>> Men jeg har et Circle-K benzinkort, så jeg kunne godt finde på at søge
>> efter benzinstationer med operator=Circle-K, som jeg forventer finder
>> både Circle-K, 1-2-3 (og Statoil, hvis der er nogen, der stadig hedder
>> det)
> 
> Jeg kender til adskillige stationer hvor der stadig er store Statoil skilte.

Det tænkte jeg nok. Derfor omdøber jeg også kun de stationer, jeg selv
har set.

>> Benzinstationen på den anden side af krydset er nu en Bonus station,
>> der stadig drives af Uno-X og stadig tager Uno-X kort.
>>
>> Der er en grund til, at der flere tags for benzinstationer. De behøver
>> ikke at have samme værdi.
> 
> Ok, men så vil jeg sætte pris på at vi får lavet en klar vejledning i hvornår 
> vi bruger hvilke tags og til hvad., for der har vitterligt ikke været nogen 
> som helst konsistens i det.

Det har været diskuteret lidt før her på listen. Så vidt jeg husker var
vi i det mindste enige om at bruge navne, som siger brugerne noget. Dvs.
fx Circle K og ikke Alimentation Couche-Tard som er de egentlige ejere.

Og det handler vel bare om at sætte tags til noget fornuftigt. Fx
Operator tags på benzinstationer.

Det gør vi jo også med andre knuder. Der er fx Irma-butikker, der er
tagget med operator=COOP. Hvis Irma en dag bliver selvstændigt igen
eller solgt til Dansk Supermarked, så skal vi også opdatere alle de tags.



-- 
Niels Elgaard Larsen

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


[OSM-talk-fr] State of the Map Cameroun 2017 à Yaoundé (1er décembre)

2017-09-26 Thread Philippe Verdy
C'est encore une ébauche sur le wiki:

https://wiki.openstreetmap.org/wiki/FR:State_of_the_Map_Cameroun_2017

Mais le site de la conférence plus générale concernant les premières
«Journées nationales de la géomatique» est complet :

http://geomatique237.xyz/

J'ai du créer la page wiki (elle manquait sur le calendrier du wiki) car
j'avais du mal à trouver le site internet, jusqu'à ce que je tombe sur une
annonce Facebook, puis le site officiel.

Ainsi l'association OpenStreetMap Cameroun va éclore ! Bonne aventure à eux
!
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


[Talk-lt] Artėja tikslaus ir prieinamo GPS laikai

2017-09-26 Thread Ričardas
Broadcom pristatė chipą smartphone'ams ir panašiai ir jau kitais metais bus
telefų su gps tikslumu iki 30cm

http://investors.broadcom.com/phoenix.zhtml?c=203541=irol-newsArticle=2302120

Tik,  ko gero,  telefonuose pozicijos atnaujinimo dažnio padidinimo iki
10Hz tikėtis neverta. Bet naujiena puiki.

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


Re: [Talk-dk] Standardisering af tankstationer i DK

2017-09-26 Thread Michael Andersen
On tirsdag den 26. september 2017 16.24.56 CEST o...@workmail.com wrote:
> En anden gang var det måske på sin plads at tage debatten før man kaster sig
> ud i at masse- rette.

Det har du fuldstændig ret i. Jeg har i en række situationer ikke været så god 
til at spørge på listen her, som det kunne ønskes. På den anden side startede 
processen egentlig i det små for år tilbage og har kun gradvist grebet om sig. 
Den har også langt hen ad vejen været nødvendig for at kunne danne mig et 
rimeligt klart overblik over situationen.
Arbejdet har også betydet at Jeg undervejs har opdaget og rettet et større 
antal relaterede fejl, hvilket alt i alt skulle betyde at det nu er langt 
lettere at danne sig et overblik over hvad vi har (via Overpass-søgninger) og 
hvad der eventuelt kunne gøres bedre.

> > Sent: Tuesday, September 26, 2017 at 3:18 PM
> > From: "Niels Elgaard Larsen" 
> > To: talk-dk@openstreetmap.org
> > Subject: Re: [Talk-dk] Standardisering af tankstationer i DK
> > 
> > On Tue, 26 Sep 2017 13:34:59 +0200
> > 
> > Michael Andersen  wrote:
> > > Jeg har nu i en del år set på og håndteret et stort tankstationer i
> > > OSM og det har været helt tydeligt at der ikke har været nogen helst
> > > konsistens i forhold til hvordan de skulle tagges.
> > > 
> > > Nogle har f.eks. været tagget med både operator=OK & name=OK &
> > > brand=OK, mens andre har været tagget med kun en enkelt af disse
> > > eller diverse kombinationer. Det forekommer mig i langt de fleste
> > > tilfælde aldeles unødvendigt at bruge mere end et af disse tags og
> > > det kan også være ret uheldigt at bruge mere end et af disse idet jeg
> > > adskillige gange har set folk ændre det ene tag, men ikke det/ de
> > > andre, når en station har fået nyt navn.
> > 
> > Wikien lægger ret meget op til at bruge alle tre felter, når det giver
> > mening.
> > 
> > > Jeg forstår udmærket hvis andre end jeg har været forvirrede over
> > > hvordan disse bedst skulle tagges idet de forskellige editorer har
> > > haft felter for alle 3 tags (hvilken er så den "rigtige"?)
> > > 
> > > Fornyligt besluttede jeg mig så for at begynde at rydde op i de
> > > danske tankstationer (vi har pt ca 1800 i OSM) og at standardisere
> > > til kun at bruge name tagget.
> > 
> > Det er jeg ked af.
> > Se fx:
> > https://www.openstreetmap.org/node/611352900
> > 
> > For det første har Statoil vel skiftet navn til Circle-K.
> > 
> > Men der har aldrig stået hverken Statoil eller Circle-K på den
> > benzinstation.
> > Der står 1-2-3 med store bogstaver. Det er meget forvirrende, når
> > sætter name-tagget til noget helt andet, end stederne kalder sig selv.
> > 
> > Men jeg har et Circle-K benzinkort, så jeg kunne godt finde på at søge
> > efter benzinstationer med operator=Circle-K, som jeg forventer finder
> > både Circle-K, 1-2-3 (og Statoil, hvis der er nogen, der stadig hedder
> > det)
> > 
> > Benzinstationen på den anden side af krydset er nu en Bonus station,
> > der stadig drives af Uno-X og stadig tager Uno-X kort.
> > 
> > Der er en grund til, at der flere tags for benzinstationer. De behøver
> > ikke at have samme værdi.
> > 
> > > Derfor har langt størstedelen af danske tankstationer nu kun et name
> > > tag og ikke noget brand eller operator tag.
> > > 
> > > Desuden har jeg i noget tid eksperimenteret med at bruge https://
> > > wiki.openstreetmap.org/wiki/Key:branch og derfor ændret en stor del
> > > fra at hedde f.ek.s "OK et-eller-andet-stednavn" til kun at hedde
> > > "OK" og så at have stednavnet i branch tagget
> > > 
> > > I en del tilfælde rundt omkring kan man se hvordan butikker der
> > > ligger tæt på hinanden "skygger" for hinandens navne (fordi der på
> > > kortet kun er plads til det ene navn) og dette problem bliver kun
> > > værre når man tilføjer stednavne til butikkernes egentlige navn
> > > (hvilket i forbindelse med f.eks. supermarkedskæder & tankstationer
> > > mm længe har været almindeligt)
> > > 
> > > Mvh Hjart
> > > 
> > > ___
> > > Talk-dk mailing list
> > > Talk-dk@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-dk
> > 
> > ___
> > Talk-dk mailing list
> > Talk-dk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-dk
> 
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk



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


[Talk-br] Como ser um nó de banco de dados do OSM?

2017-09-26 Thread Rodrigo M. Mariano
 

Olá a todos, boa tarde, 

Eu tinha lido em algum lugar, sobre
instituições poderem criar um nó de 

banco de dados do OSM, mas não
estou encontrando mais sobre isso. 

Isto é realmente possível? Se sim,
alguém poderia me passar, por favor, 

as instruções de como podermos
ser um nó de BD do OSM? 

Nós aqui do INPE estamos pensando em criar um
servidor que seja nó do OSM, que 

terão os dados de um projeto nosso,
por isso gostaria de avaliar a possibilidade. 

Atenciosamente, 
--


Rodrigo M. Mariano

Departamento de Tecnologia da Informação do
Laboratório Associado de Computação e Matemática Aplicada -
LAC
Instituto Nacional de Pesquisas Espaciais - INPE
Av. dos
Astronautas, 1.758 - Jardim da Granja
CEP: 12227-010 - São José dos
Campos/SP.
Tel.: (12) 3208-6544
 ___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br


[Talk-ca] Great Lakes disappearing again!

2017-09-26 Thread Pilon, Michel (SSC/SPC)
Hello all,

I already asked that question in the past but I still have the issue.

Objective:  To have an operational OSM server.

Last Thursday September 21st I populate my PostGIS database using the following 
command:

osm2pgsql --create --slim --flat-nodes /data/osm/pgload/flat_nodes.bin \
 -C 27000 --number-processes 8 --hstore --keep-coastlines \
 --style /data/osm/openstreetmap-carto-3.2.0/openstreetmap-carto.style \
 --multi-geometry /data/osm/new_planet-latest.osm.pbf

This morning I verified the slippymap and I can see correctly all the Great 
Lakes.

So I applied the daily updates on the data using osmosis.   Once completed, 
everything looks good EXCEPT that there is no more water on Great Lakes except 
Lac Érié and Ontario for ALL ZOOM LEVELS. Superior Lake, Michigan and Huron 
just disappeared!

I am really stuck and need help

Could it be related to the stylesheet I am using?   Which stylesheet do you 
recommend me to use if you think it can be related?

Any ideas???

Thanks,

Michel





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


[Talk-gb-westmidlands] Next meeting

2017-09-26 Thread Rob Nickerson
Hi all,

Are we back in Birmingham for Octobers meeting? I seem to recall some
discussion about trying a new venue. Where did we get to on that one?

Also I've screwed up my calendar so Thursday 5th October isn't looking that
great for me :-( I might have to skip it but throwing the idea of a one off
Wednesday meeting out there if that works for others. If not the go ahead
without me on Thursday.

*Rob*
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands


[Talk-de] mal so zwischendurch

2017-09-26 Thread Martin Koppenhoefer
Weil man sich das in Deutschland wahrscheinlich kaum vorstellen kann, hier
mal zur Info ein Beispiel für eine etwas ausführlichere Beschilderung in
Italien, wie sie durchaus kein Einzelfall ist:

https://www.dropbox.com/s/a26h145wdkw7nn6/20170920_102002.jpg?dl=0

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


Re: [Talk-de] mal so zwischendurch

2017-09-26 Thread Volker Schmidt
> https://www.dropbox.com/s/a26h145wdkw7nn6/20170920_102002.jpg?dl=0


Sieht so aus, als ob sie die Radfahrer vergessen haben. Soweit ich es lesen
kann, gelten die Verbote fuer alle Fahrzeuge, einschliesslich nicht
motorisierte, wie zum Beispiel Fahrraeder.
(es sei denn das steht im Ganzkleingedruckten)

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


Re: [Talk-de] mal so zwischendurch

2017-09-26 Thread Martin Koppenhoefer


sent from a phone

> On 26. Sep 2017, at 23:11, Volker Schmidt  wrote:
> 
> Sieht so aus, als ob sie die Radfahrer vergessen haben. Soweit ich es lesen
> kann, gelten die Verbote fuer alle Fahrzeuge, einschliesslich nicht
> motorisierte, wie zum Beispiel Fahrraeder.
> (es sei denn das steht im Ganzkleingedruckten)



theoretisch ja, praktisch wird man die aber nicht verfolgen (sind als 
Minirandgruppe wahrscheinlich schlicht vergessen/übersehen worden, das ist im 
Zentrum so üblich, bei Euch im Norden etwa nicht?). 

Denen wird es ja andererseits auch nichts ausmachen, wenn man ihnen 
elektronisch das Nummernschild auszulesen versucht ;-)

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


Re: [OSM-talk-ie] DIT study of Balbriggan

2017-09-26 Thread Donal Hunt
They may want to look at the task manager software that HOT use - it's very
good for breaking up areas and doing surveys. Should be able to run a
specific version just for their needs.

d.

On Tue, Sep 26, 2017 at 11:48 PM, Ciarán Staunton  wrote:

> Dublin Institute of Technology are running a semester long class study of
> Balbriggan. This is with their undergrads B.Sc in Environmental Management
> and Spatial Planning. They have decided to use openstreetmap for
> Balbriggan, but obviously it would need a lot of detail added to get the
> particular data they want.
>
> I have talked to their teachers and advised them on getting JOSM into their
> lab machines to do some desktop mapping initially. However, they want to
> also survey so I have recommended Mapillary, Street Complete, OSM tracker,
> and maps.me... as well as a paper solution with field papers.
>
> Has anyone else heard of a localised effort like this? I think the class
> has 20 students.
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie


Re: [OSM-talk-fr] Présentation

2017-09-26 Thread pepilepi...@ovh.fr

  
  
Le 25/09/2017 à 19:51, Cédric
  Frayssinet a écrit :


  
  Bonjour à tous,
  Nouveau sur cette liste, je me présente rapidement.
  Je suis enseignant en Sciences de l'Ingénieur à Lyon, formateur
académique au numérique et, on peut le dire, libriste...
  J'ai un compte OSM depuis 2011, mais je suis plus actif depuis
quelques mois. J'ai commencé à cartographier avec précision mon
village de vacances, puis, je suis tombé dans la marmite... bien
aidé par les applications OSMand~, StreetComplete,
OSMContributor et un peu OpenStreetCam.
  
  J'avoue, je n'utilise pas encore JOSM, seulement ID que je
trouve parfait pour débuter. Mais je compte bien m'y mettre dès
que je trouverai le temps de parcourir des tutos.
  Je me suis inscrit ici pour poser des questions de débutant,
j'espère que c'est le lieu, car les derniers me font penser
qu'il y a quelques experts dans la communauté, et c'est tant
mieux !
  Bonne soirée,
  Cédric

Bonsoir,
et bienvenue !
Sauf si j'étais particulièrement endormi ou si j'ai raté une
  marche il y a quelques trucs que je n'ai pas vu passer et qui sont
  super utiles :

  https://josm.openstreetmap.de/wiki/Introduction,
évidemment,
  ici
on trouve quelques trucs sympas,
  et bien sûr la bible du
  clavier, où j'avoue qu'il me reste quelques obscurités.
  

Oui, ça concerne JOSM, c'est le seul que j'utilise après des
  débuts avec ID.
Bon amusement !
(et merci pour tes futures contributions)
Jean-Pierre


  
  
  -- 
En cure de désintoxication de Google !
  Client d'Enercoop, l'énergie militante
Également sur Mastodon : @bristow...@framapiaf.org

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




  


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


Re: [Talk-cz] Import dat do QGisu

2017-09-26 Thread Jachym Cepicky
možná trochu pozdě, ale do qgis bych z geofabriky importoval shapefily, je
to i mene narocnejsi a vic gos friendly

j

On Wed, 20 Sep 2017, 22:53 Vladimír Semotán  wrote:

> Zdravím,
> jo, počítám s tím, že tam ta obálka bude. Když ne, tak zkrátka smůla.
> Tohle už mám zhruba naprogramované a zdá se, že funguje. Takže to je
> happy-end a děkuji za rady:-). Teď jsem od geometrie trochu odbočil a
> připravuju texturovací systém. To bude možná pro OSM premiéra. V těch 3D
> generátorech alá f4map jsou jen prázdné zdi. Já naopak volím vždy nějakou
> texturu... i kdyby to nebyla pravda :-).
>
> Stejně ale bohužel pořád nevím, jestli nakonec OSM data budu moct použít.
> Ta ODbL licence je dost krutá :-(. Už jen umístění budov na terén podle
> nějakého DEM, který není free, znamená pravděpodobně nepoužitelnost.
> Používáme i jiné databáze vázané různými licencemi. Je to zkrátka komerční
> produkt (byť bez masové distribuce).
>
> ..no trochu jsem se rozpovídal.
>
> Ještě jednou díky za reakce.
>
> V.
>
> Dne 20. září 2017 21:21 Jan Macura  napsal(a):
>
> Ahoj,
>>
>> 2017-09-20 15:24 GMT+02:00 jzvc :
>>
>>> Jeste dodam, takhle nejak to pak vypada, kdyz tam ta relace neni ...
>>>
>>>
>>> http://demo.f4map.com/#lat=50.0871190=14.420=20=52.162=24.637
>>>
>>> je tam pekny - nonOSM model radnicni veze, a kolem visej ve vzduchu veze
>>> OSM modelu, ktery nema relaci.
>>
>>
>> Musel jsem otevřít JOSM a projít všechny tagy okolních objektů, abych
>> usoudil, že ten model s texturama si tam F4 přidali sami.
>> Nijak neobhajuju neexistenci building relace, ale zrovna v tomhle případě
>> ty věžičky, co lítaj vzduchem, mohli odstranit z výsledku během
>> preprocessingu dat...
>>
>> H.
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>>
>> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


[OSM-talk-fr] GeoCodage et uMap

2017-09-26 Thread Cédric Frayssinet
Voici ma première question...

Nous avons besoin de créer une map personnalisée et nous avons
naturellement pensé à uMap. Notre fichier csv comprends ces colonnes :

/Nom Etablissement, Commune, Nom, Prénom, Courriel/

Je ne vous cache pas que des collègues ont réussi à faire une carte
Google en 2 clics avec ce fichier. Existe-t-il une solution relativement
simple pour faire une uMap avec ce type de données ?

J'ai trouvé cet excellent site https://dogeo.fr/_apps/DoGeocodeur/ qui
permet de faire du geocodage, mais c'est à partir d'une adresse précise
: n°, rue, CP, commune.

Une idée ?

Merci d'avance, Cédric



-- 
En cure de désintoxication  de
Google ! Client d'Enercoop
, l'énergie militante

Également sur Mastodon : @bristow...@framapiaf.org


Promouvoir et soutenir le logiciel libre 

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


Re: [OSM-talk-fr] GeoCodage et uMap

2017-09-26 Thread Jo
Ce serait plus facile, si le fichier csv avait déjà longitude,latitude. On
peud définir une couche CSV en umap avec 'données externes'. Je suppose
qu'il faudra donc d'abord faire le géocodage.

Jo

2017-09-26 18:33 GMT+02:00 Cédric Frayssinet :

> Voici ma première question...
>
> Nous avons besoin de créer une map personnalisée et nous avons
> naturellement pensé à uMap. Notre fichier csv comprends ces colonnes :
>
> *Nom Etablissement, Commune, Nom, Prénom, Courriel*
>
> Je ne vous cache pas que des collègues ont réussi à faire une carte Google
> en 2 clics avec ce fichier. Existe-t-il une solution relativement simple
> pour faire une uMap avec ce type de données ?
>
> J'ai trouvé cet excellent site https://dogeo.fr/_apps/DoGeocodeur/ qui
> permet de faire du geocodage, mais c'est à partir d'une adresse précise :
> n°, rue, CP, commune.
>
> Une idée ?
>
> Merci d'avance, Cédric
>
>
>
> --
> En cure de désintoxication  de Google
> ! Client d'Enercoop ,
> l'énergie militante
>
> Également sur Mastodon : @bristow...@framapiaf.org
> 
>
> [image: Promouvoir et soutenir le logiciel libre] 
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Contribution arbres remarquables du Bas-Rhin

2017-09-26 Thread PIERRE Sylvain
Effectivement pour le Bas-Rhin nous avons toutes les informations descriptives 
des arbres et nous nous appuyons sur un thésaurus pour les espèces


→  Sylvain PIERRE
 Chef de projet système d’information
 Direction des Systèmes d’Information
 Service Projets et Applications Numériques
   Conseil Départemental du Bas-Rhin

[cid:image003.jpg@01D336EC.E346DC10]

 Hôtel du Département
 1 place du Quartier Blanc 67964 Strasbourg Cedex 9
 Tél : 03 88 76 68 88 - mobile :
 Mobile : 06 30 96 31 76
 Email : sylvain.pie...@bas-rhin.fr
 www.bas-rhin.fr


De : Vincent Frison [mailto:vincent.fri...@gmail.com]
Envoyé : mardi 26 septembre 2017 15:22
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Contribution arbres remarquables du Bas-Rhin


Le 26 septembre 2017 à 12:09, Jean-Marc Liotier 
> a écrit :
On Tue, 26 Sep 2017 10:44:10 +0200 (CEST)
Vincent de Château-Thierry > wrote:
>
> > De: "PIERRE Sylvain" 
> > >
> >
> > Cet inventaire comporte un volet géographique visible ici :
> > http://sigweb.bas-rhin.fr/arbrem/ , plus de 250 arbres étant
> > recensés à ce jour. Notre collectivité souhaiterai pouvoir « pousser
> > » ces arbres dans OSM.
>
> Compte tenu du volume de données, relativement modeste, il n'y a
> peut-être pas lieu de trop phosphorer sur un "import" [..]

Certes, mais... Il y a cinq ans, mon ambition était d'utiliser le cas
des arbres remarquables, peu nombreux, pour rôder le processus de
synchronisation avant de l'appliquer aux arbres d'alignements et autres
arbres des Hauts-de-Seine considérablement plus nombreux - beaucoup trop
pour une gestion manuelle.

Hello,

Il y a 2 ans j'avais fait un script pour importer les arbres de la ville de la 
Nice (environ 30 000 arbres). Si vous botte je pourrais l'adapter avec plaisir 
pour d'autres imports, il est prévu pour...

D'ailleurs c'est marrant car à l'époque un certain Pierre m'avait contacté pour 
savoir s'il pouvait pas utiliser mon script pour importer les arbres des 
Hauts-de-Seine justement ! Mais de ce qu'il me disait il avait un gros doute 
sur la précision des positions des arbres et en fait on avait pas creusé plus 
que cela...

La valeur ajoutée est bien plus grande s'il y a plus que la simple localisation 
des arbres, ce qui n'était malheureusement pas le cas pour Nice. Le top c'est 
d'avoir le type / genre de l'arbre ce qui est certainement le cas pour les 
arbres du Bas-Rhin et des Hauts-de-Seine (au vu de ta page wiki de Jean-Marc).

++ Vincent


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


Re: [OSM-talk-fr] Présentation

2017-09-26 Thread Cédric Frayssinet

Merci pour vos retours et vos encouragements à utiliser JOSM :)

Je vais pouvoir commencer à poser mes questions !

Je vous informe également que je viens de rédiger un article sur notre
site à la Délégation Académique au Numérique Éducatif de Lyon :
https://dane.ac-lyon.fr/spip/OpenStreetMap-la-cartographie
Cet article se veut accessible, et il est plutôt à destination des
enseignants afin qu'il donne envie d'utiliser OpenStreetMap dans leurs
séquences pédagogiques ; j'ai mis à la fin quelques exemples de scenarii.


Cédric


Le 26/09/2017 à 15:11, Philippe Verdy a écrit :
> Perso je n'utilise jamais A (ajout): le clic sur l'icone d'outil de
> tracé suffit bien.
>
> En revanche Ctrl+Alt+D (charger les objets parents) est indispensable.
> Si on n'arrive pas à le taper, utiliser le menu Préférences pour
> personnaliser la barre d'outils et y inclure l'icone pour cette
> commande indispensable avant toute scission ou fusion de chemins !
> Indispensable si on travaille sur la voirie pour ne pas casser les
> relations d'itinéraires de transport, ou sur des frontières pour ne
> pas créer de trous ou déplacer à tord un point triple (jonction de
> trois frontières)
>
> Et plus utile encore :
>
> M pour déplacer un bâtiment entier, R pour le faire pivoter en entier
> (utile quand on ajoute des bâtiments simples par exemple pour HOT): on
> en trace un (qui est un simple rectangle), on met l'attribut
> building=yes, on vérifie qu'il est rectangulaire (Q), puis on fait
> CTRL+C pour le copier.
> Ensuite on se positionne où on doit en créer un nouveau, puis CTRL+V
> pour coller une copie, puis R pour le faire pivoter au bon angle, M
> (minuscule) pour caler un des coins en déplaçant finement, enfin on
> ajuste les trois autres angles et Q pour le régulariser, et au besoin
> on ajuste encore un peu les coins et Q à nouveau. On passe au bâtiment
> suivant
>
> Attention à la touche CapsLock ! m et M ne font pas la même chose (m
> pour déplacer, SHIFT+M pour fusionner des points superposés).
>
> Tous ces raccourcis clavier sont personnalisables dans JOSM.
>
> On fait la même chose avec iD avec des raccourcis claviers similaires
> (quoique un peu différents : S=square pour régulariser les angles
> droits). Personnellement pour les tâches HOT je préfère nettement iD
> qui est plus rapide et où on travaille plus localement (et CTRL+ALT+D
> n'est pas nécessaire: tous les objets parents dans la vue sont déjà
> chargés au moins partiellement pour inclure les membres visibles. La
> plupart des tâches HOT sont pour tracer des routes (ou rivières)
> manquantes ou les réajuster avant de placer les bâtiments (et ponts
> manquants).
>
> Sur iD un truc à connaitre c'est la touche ALT lorsqu'on déplace un
> point pour éviter de le fusionner avec un nœud ou un chemin proche
> (très utile pour le tracé des bâtiments en zone urbaine) et ne pas le
> coller à la route (ou à une frontière, une rivière ou une bordure de
> zone résidentielle ou forestière)
>
> JOSM est cependant préférable pour les objets de grande taille
> (notamment les frontières bien qu'on n'ait plus beaucoup de travail
> dessus en France, les itinéraires, certains gros "landuse", et les
> riverbanks. Pour tracer et affiner les plages, iD suffit bien en
> général (sauf les très longues plages de côtes peu découpées)
>
> Savoir utiliser les deux outils est utile, selon le cas on est plus
> efficace avec l'un ou l'autre, mais les relations dans iD c'est encore
> un peut trop "casse-pied" à faire dès que ça sort de la zone visible
> éditable et qu'il devient difficile de sélectionner les objets
> notamment s'il y a de très longs chemins compliqués qu'on a intérêt
> alors à scinder, quitte à les fusionner ensuite.
>
> Le 26 septembre 2017 à 14:18, Christian Quest  > a écrit :
>
> Le B A  BA de JOSM c'est:
>
> - A (ajout)
>
> - S (sélection)
>
> - F3
>
> ensuite on peut explorer le reste, mais ça c'est l'essentiel pour
> démarrer ;)
>
>
> JOSM peut faire peur au premier contact, mais l'investissement est
> d'une incroyable rentabilité quand on voit ce qu'on peut faire avec !
>
> Les tags proposés par la recherche (F3) ou le menu, proviennent de
> presets. Il y a les presets de base, mais on peut en ajouter
> d'autres via le panneau de préférence. C'est utile si on
> cartographie des objets de type un peu moins courant.
>
>
>
> Le 26/09/2017 à 12:07, marc marc a écrit :
>
> Le 26. 09. 17 à 10:48, Jo a écrit :
>
> Il n'est pas possible de faire cela en utilisant F3?
>
> j'ai toujours cru que la recherche concernait les éléments
> téléchargés
> (= retrouver l'objet qui a tel tag). mais en effet cela permet
> aussi
> de chercher un tag qui n'est pas encore présent sur un objet.
> Que manque-t-il ? un nettoyage par rapport au wiki.
> exemple il ne trouve pas step:contrast qui a pourtant une 

Re: [OSM-talk-fr] Présentation

2017-09-26 Thread Jo
J'ai essayé de suivre tes conseils pour JOSM, mais ça me semble bien plus
compliqué que nécessaire.

Avec buildings_tools et utilsplugin2 installés, on peut faire:

(main gauche sur le clavier, main droite sur la souris)

b (building)

3 clicks -> bâtiment rectangulaire. (2 clicks suffisent si on le lance avec
quelque chose de sélectionné)

s + sélectionner avec la souris

Aller autre part et Ctrl-d (dupliquer)

Si le bâtiment a une autre forme 'w' (irmprove way accuracy) pour déplacer
les noeuds, puis 'q' pour le rendre rectangulaire à nouveau.

'x' (extrude) est un autre outil qui vaut son poids en or. Je l'utilise
souvent simplement pour ajouter des noeuds sur les way (double click).

Mais ce qu'il fait c'est créer des formes L, T, H d'une façon extrèmement
efficace. Après l'ajout d'un noeud, essayez de deplacer un des 'murs'. Mais
sans ajouter un noeud supplémentaire il peut servir pour élargir ou réduire
des bâtiments rectangulaires.

Quelque chose qui m'a pris beaucoup de temps de découvrir c'est

Ctrl-Alt-Left mouse button pour élargir ou réduire une forme.

Ctrl-Shif-Left mouse button pour faire une rotation.

Ce qui est pratique aussi, c'est si on fait 'a a' (2 fois) on peut faire
des angles de 15/30/45/.../90 dégrées entre 2 bouts de chemins.

's s' donne un 'lasso' pour faire une sélection 'aléatoire'.

Si on sélectionne quelque chose et puis on sélectionne un autre object, on
peut 'répeter' les tags avec Shift-R. 'r' tout seul fait un 'reverse way'.

Le programme est vraimment bourré d'outils et on n'a même pas encore
mentionné comment sélectionner ou faire des recherches dans les données, ou
activer des filtres pour désactiver ce dont on n'a pas besoin (dans mon
cas: les landuse et les frontières...)

Ou les styles MapCSS pour mettre en vigueur les données qui sont
intéressantes pour la tâche qu'on essaye d'accomplir. Les turn lanes, ou
les itinéraires cyclistes/ de randonnée (ou de bus, bien sûr :-) )


Allez, vaut mieux que j'arrête :-)

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


Re: [OSM-talk-fr] GeoCodage et uMap

2017-09-26 Thread osm . sanspourriel
Facile, ouim ais pour quelle qualité du résultat ? Est-ce que la précision c'est la commune ou l'établissement dans la commune?
Un des nombreux problèmes avec Google, c'est qu'on obtient vite quelque chose (et ici Google obtient plein d'info intéressantes en un clic d'un collègue, sympa. Je ne suis pas sûr que les collègues qui verront ainsi le rôle dans un établissement offert à Google apprécient).

 

Oui avec uMap ce sera sans doute plus compliqué, on imagine dans un premier temps trouver les bâtiments avec Overpass par exemple.

Mais on n'offre pas les données de ses collègues à Google.

 

Jean-Yvon


 

N.B. : pourquoi être seulement client quand on peut aussi être sociétaire d'Enercoop ? ;-)

 

Gesendet: Dienstag, 26. September 2017 um 18:33 Uhr
Von: "Cédric Frayssinet - lis...@frayssinet.org"
An: "Discussions sur OSM en français"
Betreff: [OSM-talk-fr] GeoCodage et uMap



Voici ma première question...

Nous avons besoin de créer une map personnalisée et nous avons naturellement pensé à uMap. Notre fichier csv comprends ces colonnes :

Nom Etablissement, Commune, Nom, Prénom, Courriel

Je ne vous cache pas que des collègues ont réussi à faire une carte Google en 2 clics avec ce fichier. Existe-t-il une solution relativement simple pour faire une uMap avec ce type de données ?

J'ai trouvé cet excellent site https://dogeo.fr/_apps/DoGeocodeur/ qui permet de faire du geocodage, mais c'est à partir d'une adresse précise : n°, rue, CP, commune.

Une idée ?

Merci d'avance, Cédric

 

 

--
En cure de désintoxication de Google ! Client d'Enercoop, l'énergie militante

Également sur Mastodon : @bristow...@framapiaf.org



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






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


Re: [Talk-us] Recent Aerial Photo Imagery Changes

2017-09-26 Thread Mark Wagner
On Tue, 26 Sep 2017 11:07:55 +0300
Rihards  wrote:

> On 2017.09.26. 03:09, David Wisbey wrote:
> > Fellow mappers,
> > 
> > So what's up with the recent changes in our aerial photo imagery?
> > 
> > It used to be so simple and I followed the rule(?) of making sure
> > features line up with Bing imagery.  I'm wondering about that now -
> > big time. I have been mapping in a variety of locations lately and
> > the situation is different in each location.  In Minnesota, for
> > instance, I really don't want to use Bing imagery unless at some
> > zoom level it shows me the most current images (especially in high
> > growth areas like northwest Rochester). And when recently updating
> > an intersection in southwest Minnesota to a new roundabout, I was
> > aghast at what Bing was giving me and so only used it where the
> > quality/resolution "wasn't TOO bad". Sad. Mapbox, ESRI and other
> > imagery were all much better choices, especially between Blomkest
> > and Hutchinson, MN.
> > 
> > So the main question now is: Does the "line up with Bing" rule
> > still stand? In recent work around the city of Virginia, Minnesota
> > (re-routing of US 53) I felt I had to use Mapbox imagery and so
> > lined up what I could with it rather
> > than Bing. In most cases, they matched or were off by only 2 meters
> > or so.  
> 
> there has never been a rule to "line up with Bing", quite the
> opposite - you should not unconditionally line up with any imagery
> layer, unless you know for sure it's extremely precise.
> regarding imagery layers like sat/ortophoto, it has always been
> suggested to check and align them to gps traces from the area (while
> keeping in mind that one or few traces might be all wrong, the centre
> line of many traces being the best).

When possible, I line up imagery to Strava cycle heatmaps -- Strava's
already done the work of averaging dozens/hundreds of traces for you.
When doing this, keep in mind that, especially in hilly areas, cyclists
sometimes prefer one direction of travel over another, biasing the peak
to one side or the other.  Alignment to Strava works best when you've
got two distinct peaks from the shoulders of a road, or a single narrow
peak from a dedicated bicycle route.

With the old Bing imagery, I usually didn't bother, since the
disagreement between Bing and Strava was usually less than the
resolution of the imagery.  With the new imagery, I prefer not to use
the imagery unless I can align a nearby feature to something I know is
reasonably accurate (and when mapping locally, I don't use Bing at all
-- ESRI is newer, better-aligned, and has resolution that would let
me map the shingles on a roof.)

-- 
Mark

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


Re: [OSM-talk-fr] Présentation

2017-09-26 Thread Philippe Verdy
Perso je n'utilise jamais A (ajout): le clic sur l'icone d'outil de tracé
suffit bien.

En revanche Ctrl+Alt+D (charger les objets parents) est indispensable. Si
on n'arrive pas à le taper, utiliser le menu Préférences pour personnaliser
la barre d'outils et y inclure l'icone pour cette commande indispensable
avant toute scission ou fusion de chemins ! Indispensable si on travaille
sur la voirie pour ne pas casser les relations d'itinéraires de transport,
ou sur des frontières pour ne pas créer de trous ou déplacer à tord un
point triple (jonction de trois frontières)

Et plus utile encore :

M pour déplacer un bâtiment entier, R pour le faire pivoter en entier
(utile quand on ajoute des bâtiments simples par exemple pour HOT): on en
trace un (qui est un simple rectangle), on met l'attribut building=yes, on
vérifie qu'il est rectangulaire (Q), puis on fait CTRL+C pour le copier.
Ensuite on se positionne où on doit en créer un nouveau, puis CTRL+V pour
coller une copie, puis R pour le faire pivoter au bon angle, M (minuscule)
pour caler un des coins en déplaçant finement, enfin on ajuste les trois
autres angles et Q pour le régulariser, et au besoin on ajuste encore un
peu les coins et Q à nouveau. On passe au bâtiment suivant

Attention à la touche CapsLock ! m et M ne font pas la même chose (m pour
déplacer, SHIFT+M pour fusionner des points superposés).

Tous ces raccourcis clavier sont personnalisables dans JOSM.

On fait la même chose avec iD avec des raccourcis claviers similaires
(quoique un peu différents : S=square pour régulariser les angles droits).
Personnellement pour les tâches HOT je préfère nettement iD qui est plus
rapide et où on travaille plus localement (et CTRL+ALT+D n'est pas
nécessaire: tous les objets parents dans la vue sont déjà chargés au moins
partiellement pour inclure les membres visibles. La plupart des tâches HOT
sont pour tracer des routes (ou rivières) manquantes ou les réajuster avant
de placer les bâtiments (et ponts manquants).

Sur iD un truc à connaitre c'est la touche ALT lorsqu'on déplace un point
pour éviter de le fusionner avec un nœud ou un chemin proche (très utile
pour le tracé des bâtiments en zone urbaine) et ne pas le coller à la route
(ou à une frontière, une rivière ou une bordure de zone résidentielle ou
forestière)

JOSM est cependant préférable pour les objets de grande taille (notamment
les frontières bien qu'on n'ait plus beaucoup de travail dessus en France,
les itinéraires, certains gros "landuse", et les riverbanks. Pour tracer et
affiner les plages, iD suffit bien en général (sauf les très longues plages
de côtes peu découpées)

Savoir utiliser les deux outils est utile, selon le cas on est plus
efficace avec l'un ou l'autre, mais les relations dans iD c'est encore un
peut trop "casse-pied" à faire dès que ça sort de la zone visible éditable
et qu'il devient difficile de sélectionner les objets notamment s'il y a de
très longs chemins compliqués qu'on a intérêt alors à scinder, quitte à les
fusionner ensuite.

Le 26 septembre 2017 à 14:18, Christian Quest  a
écrit :

> Le B A  BA de JOSM c'est:
>
> - A (ajout)
>
> - S (sélection)
>
> - F3
>
> ensuite on peut explorer le reste, mais ça c'est l'essentiel pour démarrer
> ;)
>
>
> JOSM peut faire peur au premier contact, mais l'investissement est d'une
> incroyable rentabilité quand on voit ce qu'on peut faire avec !
>
> Les tags proposés par la recherche (F3) ou le menu, proviennent de
> presets. Il y a les presets de base, mais on peut en ajouter d'autres via
> le panneau de préférence. C'est utile si on cartographie des objets de type
> un peu moins courant.
>
>
>
> Le 26/09/2017 à 12:07, marc marc a écrit :
>
>> Le 26. 09. 17 à 10:48, Jo a écrit :
>>
>> Il n'est pas possible de faire cela en utilisant F3?
>>>
>> j'ai toujours cru que la recherche concernait les éléments téléchargés
>> (= retrouver l'objet qui a tel tag). mais en effet cela permet aussi
>> de chercher un tag qui n'est pas encore présent sur un objet.
>> Que manque-t-il ? un nettoyage par rapport au wiki.
>> exemple il ne trouve pas step:contrast qui a pourtant une page wiki
>> il trouve step.condition qui n'a qu'une page de proposition (et qui
>> ne passerait à mon avis pas le vote vu le point comme séparateur)
>> Mais merci pour cette info du F3 bien pratique.
>> ___
>> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-Talk-ZA] Fwd: OpenWaterMap? map of water seepage on UCT campuses

2017-09-26 Thread Gerhardus Geldenhuis
Hi
Not familiar with umap but it looks like it would fit well with your needs
and it is OSM friendly. If you wanted to put the data directly in
OpenStreetMap then hotosm have a tool that allows you to divide an area
into blocks that people can work on. That is a great way to divvy up work
and see what areas has been completed. The link is http://tasks.hotosm.org/
You can either use that in situ or you can build your own version since it
is opensource.

Regards

On 26 September 2017 at 09:35, Bernelle Verster  wrote:

> Hi
>
> I've been tasked with creating a way for the University of Cape Town
> (UCT) community to pin locations of water seepage (details below). I'd
> like to eventually use this application to contribute to assisting
> people to understand the locations and risks of alternative water
> sources ('springs' and groundwater, mainly) as we move towards water
> sensitive settlements [1,2], so it's important to do this well.
>
> uMap has been suggested, and looks good [3]. My next step is to figure
> out how it works, so any help is welcome :) Also if anything like this
> exists already that I can fork (I think that's the right use of the
> word) or join, please let me know
>
> Someone else suggested using OpenGreenMap [4,5]. They seem to want to
> be open but they use google maps (I think??), which as far as I
> understand is not open. My question is, if this is compatible with
> OSM, it would be good to contribute through this way. Is this
> possible/a good idea?
>
> thanks
> indiebio
>
> [1] - iwa-network.org/projects/water-wise-cities
> [2] - http://www.futurewater.uct.ac.za/FW-wsd
> [3] - http://umap.openstreetmap.fr/en/
> [4] - http://www.opengreenmap.org/home
> [5] - http://www.capetowngreenmap.co.za/interactive-green-map
>
>
>
> -- Forwarded message --
> From: Bernelle Verster 
> Date: Fri, Sep 22, 2017 at 2:13 PM
> Subject: OpenWaterMap? map of water seepage on UCT campuses
> To: futurewaterforu...@lists.uct.ac.za
>
>
> Dear all
>
> Kevin Winter who heads up the UCT Water Task Team would like help from
> the UCT community to help identify the location of water seepage (aka
> springs) on the various campuses. There are apparently loads of them.
> Some are weak running at 1 litre / 20 seconds but others are filling
> the basement of buildings right now.
>
> We'd like to find these discharge points and identify them on a map
> (e.g. google or Open Street Maps - https://www.openstreetmap.org)
>
> We could then ask people to pin these points of discharge onto the
> map. Once we have the locations a team can go out to inspect the sites
> and see if we can capture the water in tanks and obviously also see
> what use could be made of the water. An image of the location would
> also help.
>
> Please note that this is in addition to a water audit that will be
> conducted soon.
>
> Do any of you know if there are any such initiatives in existence
> already that we can link up to or adapt for UCT? Any coders/developers
> keen to get involved?
> Any suggestions or comments on how to implement this?
>
> Next week we expect a reasonable rainfall and these springs should be
> running well. Its an opportunity to identify them and to launch the
> activity later next week.
>
> Further ideas - gamify it?
> geocaching
> augmented reality
> gamification
>
> Looking forward, in the long term:
> In the context of alternative water sources, blue green infrastructure
> and water sensitive design - in short, making water more visible -
> even when the drought is over, we need a handle to assist the public
> on how to manage their water resources, and the risk associated with
> it.
>
> In the current context of the drought, it would be great if we can map
> water resources - springs and groundwater, for example - and indicate
> their relative safety (e.g. Newlands is safe to drink, the 'spring'
> water at St James is not (I think)). As groundwater quality depends on
> its surroundings and the soil composition it would be good to map that
> too, and suggest interventions/tests required. I envisage this to be a
> community driven thing, not delivered by consultants or scientists. I
> also see that this may not be something that Future Water or the City
> want to take responsibility for due to potential liability issues.
> Thus I think it would need to be independently hosted - is this
> assessment correct?
>
> Related to this we are trying to figure our what is an appropriate
> level of analysis we can advise the public - meeting with Scientific
> Services gave the 'it's too complicated that's why it's expensive'
> answer, which may be correct but does not assist the public who are
> going ahead and doing silly things anyway.
>
> Looking forward to hearing your thoughts.
>
> ___
> Talk-ZA mailing list
> Talk-ZA@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-za
>



-- 
Gerhardus Geldenhuis

Re: [Talk-dk] Standardisering af tankstationer i DK

2017-09-26 Thread Michael Andersen
On tirsdag den 26. september 2017 15.18.25 CEST Niels Elgaard Larsen wrote:
> On Tue, 26 Sep 2017 13:34:59 +0200
> 
> Michael Andersen  wrote:
> > Jeg har nu i en del år set på og håndteret et stort tankstationer i
> > OSM og det har været helt tydeligt at der ikke har været nogen helst
> > konsistens i forhold til hvordan de skulle tagges.
> > 
> > Nogle har f.eks. været tagget med både operator=OK & name=OK &
> > brand=OK, mens andre har været tagget med kun en enkelt af disse
> > eller diverse kombinationer. Det forekommer mig i langt de fleste
> > tilfælde aldeles unødvendigt at bruge mere end et af disse tags og
> > det kan også være ret uheldigt at bruge mere end et af disse idet jeg
> > adskillige gange har set folk ændre det ene tag, men ikke det/ de
> > andre, når en station har fået nyt navn.
> 
> Wikien lægger ret meget op til at bruge alle tre felter, når det giver
> mening.
> 
> > Jeg forstår udmærket hvis andre end jeg har været forvirrede over
> > hvordan disse bedst skulle tagges idet de forskellige editorer har
> > haft felter for alle 3 tags (hvilken er så den "rigtige"?)
> > 
> > Fornyligt besluttede jeg mig så for at begynde at rydde op i de
> > danske tankstationer (vi har pt ca 1800 i OSM) og at standardisere
> > til kun at bruge name tagget.
> 
> Det er jeg ked af.
> Se fx:
> https://www.openstreetmap.org/node/611352900
> 
> For det første har Statoil vel skiftet navn til Circle-K.
> 
> Men der har aldrig stået hverken Statoil eller Circle-K på den
> benzinstation.
> Der står 1-2-3 med store bogstaver. Det er meget forvirrende, når
> sætter name-tagget til noget helt andet, end stederne kalder sig selv.

Der står faktisk Statoil på skiltet ved den station (se https://
www.mapillary.com/map/im/ND1v2JKNGlQ30_iSVi4mTA) og lige nedenunder med en 
anelse mindre bogstaver står der 1-2-3. 
Jeg kommer jævnligt selv forbi, men må da indrømme at jeg har undret mig over 
hvad der mon var det rette primære navn og har derfor efterfølgende ikke 
rettet andre.
> 
> Men jeg har et Circle-K benzinkort, så jeg kunne godt finde på at søge
> efter benzinstationer med operator=Circle-K, som jeg forventer finder
> både Circle-K, 1-2-3 (og Statoil, hvis der er nogen, der stadig hedder
> det)

Jeg kender til adskillige stationer hvor der stadig er store Statoil skilte.
> 
> Benzinstationen på den anden side af krydset er nu en Bonus station,
> der stadig drives af Uno-X og stadig tager Uno-X kort.
> 
> Der er en grund til, at der flere tags for benzinstationer. De behøver
> ikke at have samme værdi.

Ok, men så vil jeg sætte pris på at vi får lavet en klar vejledning i hvornår 
vi bruger hvilke tags og til hvad., for der har vitterligt ikke været nogen 
som helst konsistens i det.

> 
> > Derfor har langt størstedelen af danske tankstationer nu kun et name
> > tag og ikke noget brand eller operator tag.
> > 
> > Desuden har jeg i noget tid eksperimenteret med at bruge https://
> > wiki.openstreetmap.org/wiki/Key:branch og derfor ændret en stor del
> > fra at hedde f.ek.s "OK et-eller-andet-stednavn" til kun at hedde
> > "OK" og så at have stednavnet i branch tagget
> > 
> > I en del tilfælde rundt omkring kan man se hvordan butikker der
> > ligger tæt på hinanden "skygger" for hinandens navne (fordi der på
> > kortet kun er plads til det ene navn) og dette problem bliver kun
> > værre når man tilføjer stednavne til butikkernes egentlige navn
> > (hvilket i forbindelse med f.eks. supermarkedskæder & tankstationer
> > mm længe har været almindeligt)
> > 
> > Mvh Hjart
> > 
> > ___
> > Talk-dk mailing list
> > Talk-dk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-dk
> 
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk



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


Re: [OSM-talk-fr] Présentation

2017-09-26 Thread Christian Quest

Le B A  BA de JOSM c'est:

- A (ajout)

- S (sélection)

- F3

ensuite on peut explorer le reste, mais ça c'est l'essentiel pour 
démarrer ;)



JOSM peut faire peur au premier contact, mais l'investissement est d'une 
incroyable rentabilité quand on voit ce qu'on peut faire avec !


Les tags proposés par la recherche (F3) ou le menu, proviennent de 
presets. Il y a les presets de base, mais on peut en ajouter d'autres 
via le panneau de préférence. C'est utile si on cartographie des objets 
de type un peu moins courant.



Le 26/09/2017 à 12:07, marc marc a écrit :

Le 26. 09. 17 à 10:48, Jo a écrit :


Il n'est pas possible de faire cela en utilisant F3?

j'ai toujours cru que la recherche concernait les éléments téléchargés
(= retrouver l'objet qui a tel tag). mais en effet cela permet aussi
de chercher un tag qui n'est pas encore présent sur un objet.
Que manque-t-il ? un nettoyage par rapport au wiki.
exemple il ne trouve pas step:contrast qui a pourtant une page wiki
il trouve step.condition qui n'a qu'une page de proposition (et qui
ne passerait à mon avis pas le vote vu le point comme séparateur)
Mais merci pour cette info du F3 bien pratique.
___
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-cz] rozcestniky

2017-09-26 Thread Tom Ka
Mirror uz se davno dela na osm.fit.vutbr.cz.

Dne 26. září 2017 8:50 Michal Grézl  napsal(a):
> 2017-09-21 20:07 GMT+02:00 o...@kub.cz :
>> Nabízím hostování na svém serveru, který umístěn přímo na optické páteřní
>> síti a momentálně tam je ještě tak TB volno. Hostuji tam neziskové projekty
>> které znám nebo jsem do nich zapojen, co čehož OSM spadá. Běží tam asi 15
>> webů a mailserver.
>>
>> Gorn
>>
>>
>
> no uz sem to zacal migrovat na to contabo, ale asi by se hodil nejakej mirror.
> neco ve stylu nocni rsync dat + databaze. ma to ted nejakych 30 giga.
>
>
> --
> Michal Grézl
> http://openstreetmap.cz
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

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


Re: [OSM-talk-fr] Contribution arbres remarquables du Bas-Rhin

2017-09-26 Thread Vincent Frison
Le 26 septembre 2017 à 12:09, Jean-Marc Liotier  a écrit :

> On Tue, 26 Sep 2017 10:44:10 +0200 (CEST)
> Vincent de Château-Thierry  wrote:
> >
> > > De: "PIERRE Sylvain" 
> > >
> > > Cet inventaire comporte un volet géographique visible ici :
> > > http://sigweb.bas-rhin.fr/arbrem/ , plus de 250 arbres étant
> > > recensés à ce jour. Notre collectivité souhaiterai pouvoir « pousser
> > > » ces arbres dans OSM.
> >
> > Compte tenu du volume de données, relativement modeste, il n'y a
> > peut-être pas lieu de trop phosphorer sur un "import" [..]
>
> Certes, mais... Il y a cinq ans, mon ambition était d'utiliser le cas
> des arbres remarquables, peu nombreux, pour rôder le processus de
> synchronisation avant de l'appliquer aux arbres d'alignements et autres
> arbres des Hauts-de-Seine considérablement plus nombreux - beaucoup trop
> pour une gestion manuelle.
>

Hello,

Il y a 2 ans j'avais fait un script pour importer les arbres de la ville de
la Nice (environ 30 000 arbres). Si vous botte je pourrais l'adapter avec
plaisir pour d'autres imports, il est prévu pour...

D'ailleurs c'est marrant car à l'époque un certain Pierre m'avait contacté
pour savoir s'il pouvait pas utiliser mon script pour importer les arbres
des Hauts-de-Seine justement ! Mais de ce qu'il me disait il avait un gros
doute sur la précision des positions des arbres et en fait on avait pas
creusé plus que cela...

La valeur ajoutée est bien plus grande s'il y a plus que la simple
localisation des arbres, ce qui n'était malheureusement pas le cas pour
Nice. Le top c'est d'avoir le type / genre de l'arbre ce qui est
certainement le cas pour les arbres du Bas-Rhin et des Hauts-de-Seine (au
vu de ta page wiki de Jean-Marc).

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


Re: [Talk-dk] Standardisering af tankstationer i DK

2017-09-26 Thread Niels Elgaard Larsen
On Tue, 26 Sep 2017 13:34:59 +0200
Michael Andersen  wrote:

> Jeg har nu i en del år set på og håndteret et stort tankstationer i
> OSM og det har været helt tydeligt at der ikke har været nogen helst
> konsistens i forhold til hvordan de skulle tagges.
> 
> Nogle har f.eks. været tagget med både operator=OK & name=OK &
> brand=OK, mens andre har været tagget med kun en enkelt af disse
> eller diverse kombinationer. Det forekommer mig i langt de fleste
> tilfælde aldeles unødvendigt at bruge mere end et af disse tags og
> det kan også være ret uheldigt at bruge mere end et af disse idet jeg
> adskillige gange har set folk ændre det ene tag, men ikke det/ de
> andre, når en station har fået nyt navn.


Wikien lægger ret meget op til at bruge alle tre felter, når det giver
mening.
 
> Jeg forstår udmærket hvis andre end jeg har været forvirrede over
> hvordan disse bedst skulle tagges idet de forskellige editorer har
> haft felter for alle 3 tags (hvilken er så den "rigtige"?)
> 
> Fornyligt besluttede jeg mig så for at begynde at rydde op i de
> danske tankstationer (vi har pt ca 1800 i OSM) og at standardisere
> til kun at bruge name tagget.

Det er jeg ked af.
Se fx:
https://www.openstreetmap.org/node/611352900
 
For det første har Statoil vel skiftet navn til Circle-K.

Men der har aldrig stået hverken Statoil eller Circle-K på den
benzinstation.
Der står 1-2-3 med store bogstaver. Det er meget forvirrende, når
sætter name-tagget til noget helt andet, end stederne kalder sig selv.

Men jeg har et Circle-K benzinkort, så jeg kunne godt finde på at søge
efter benzinstationer med operator=Circle-K, som jeg forventer finder
både Circle-K, 1-2-3 (og Statoil, hvis der er nogen, der stadig hedder
det)

Benzinstationen på den anden side af krydset er nu en Bonus station,
der stadig drives af Uno-X og stadig tager Uno-X kort.

Der er en grund til, at der flere tags for benzinstationer. De behøver
ikke at have samme værdi.


> Derfor har langt størstedelen af danske tankstationer nu kun et name
> tag og ikke noget brand eller operator tag.
> 
> Desuden har jeg i noget tid eksperimenteret med at bruge https://
> wiki.openstreetmap.org/wiki/Key:branch og derfor ændret en stor del
> fra at hedde f.ek.s "OK et-eller-andet-stednavn" til kun at hedde
> "OK" og så at have stednavnet i branch tagget
> 
> I en del tilfælde rundt omkring kan man se hvordan butikker der
> ligger tæt på hinanden "skygger" for hinandens navne (fordi der på
> kortet kun er plads til det ene navn) og dette problem bliver kun
> værre når man tilføjer stednavne til butikkernes egentlige navn
> (hvilket i forbindelse med f.eks. supermarkedskæder & tankstationer
> mm længe har været almindeligt)
> 
> Mvh Hjart
> 
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk


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


Re: [Talk-us] Recent Aerial Photo Imagery Changes

2017-09-26 Thread Volker Schmidt
> ... it has always been
> suggested to check and align them to gps traces from the area (while
> keeping in mind that one or few traces might be all wrong, the centre
> line of many traces being the best).
>

This is certainly the best advice (unless you are in an area with high
buildings or steep mountains, conditions which may produce systematic GPS
errors, in which case there is no recipe)
Apart from simple shift problems, satellite/areal photos may suffer, even
considerably, from vertical parallax problems. In my area (Northern Italy)
Bing maps have consistently suffered from Lat-Long shift in the order of
even 5 meters plus a superimposed parallax error that deforms road shapes
further, typically in the mountains. The parallax error becomes worse the
steeper the hills/mountains are.
To illustrate the parallax problem, have a look at this example in
California:
https://www.openstreetmap.org/edit?editor=id#map=18/35.99284/-121.48429
Compare the Bing map layer with the Mapbox map layer and also with the GPX
tracks.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


  1   2   >