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

[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] Redacting 75, 000 street names contributed by user chdr

[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: [Talk-us] Virtual Mappy Hours reboot

[Martijn van Exel]

Hi folks!
This is a reminder that we will have our first osm fireside chat / mappy hour 
tomorrow! I will be looking forward to see you then.
Martijn

> On Sep 18, 2017, at 11:46 AM, Martijn van Exel  
> wrote:
> 
> Hey all, 
> 
> I decided to give the Virtual Mappy Hours another go. The first one will be 
> next Wednesday at 5:30 pacific. We’ll talk about State of the Map US. I hope 
> you can join! Details are in this diary entry: 
> https://www.openstreetmap.org/user/mvexel/diary/42318 
> 
> 
> Martijn

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

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

[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-ie] DIT study of Balbriggan

[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] Adding wikidata tags to the remaining objects with only wikipedia tag

[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 

[Talk-gb-westmidlands] Next meeting

[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

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

[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: [Talk-it] Changeset auto-matching.

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

[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

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

[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: [Talk-de] mal so zwischendurch

[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] Downloading Version 3 of all bus stops in a country

[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: [OSM-talk] Downloading Version 3 of all bus stops in a country

[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] Downloading Version 3 of all bus stops in a country

[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-de] mal so zwischendurch

[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: [OSM-talk] Label language on the Default stylesheet

[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

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

[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] Fixing OSM wikipedia redirects

[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

[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] Downloading Version 3 of all bus stops in a country

[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: [Talk-it] Sito statistiche "Dapal"

[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] Downloading Version 3 of all bus stops in a country

[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] Adding wikidata tags to the remaining objects with only wikipedia tag

[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: [Talk-it] Chiusura fontanelle a Roma

[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: [OSM-talk] Downloading Version 3 of all bus stops in a country

[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] Downloading Version 3 of all bus stops in a country

[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

[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: [Talk-it] Sito statistiche "Dapal"

[Martin Koppenhoefer]

certo, +1 anche da me

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

[Talk-de] mal so zwischendurch

[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-it] Aiuto su conditional restrictions

[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] Sito statistiche "Dapal"

[Lorenzo "Beba" Beltrami]

+1 anch'io!

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

[Talk-ca] Great Lakes disappearing again!

[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

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

[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] Chiusura fontanelle a Roma

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

[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

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

[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

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

[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

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

[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-lt] Artėja tikslaus ir prieinamo GPS laikai

[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-it] Aiuto su conditional restrictions

[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

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

[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

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

[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: [OSM-talk] Downloading Version 3 of all bus stops in a country

[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: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

[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: [Talk-us] Recent Aerial Photo Imagery Changes

[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] Adding wikidata tags to the remaining objects with only wikipedia tag

[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

[Talk-it] Aiuto su conditional restrictions

[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: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

[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-fr] GeoCodage et uMap

[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: [OSM-talk-fr] GeoCodage et uMap

[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: [Talk-it] Chiusura fontanelle a Roma

[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

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

[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

[OSM-talk-fr] GeoCodage et uMap

[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] Présentation

[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

[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: [Talk-cz] Import dat do QGisu

[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

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

[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: [Talk-dk] Standardisering af tankstationer i DK

[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: [Talk-dk] Standardisering af tankstationer i DK

[osm]

En anden gang var det måske på sin plads at tage debatten før man kaster sig ud 
i at masse- rette.

-- 


> 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

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

[Dlareg]

Le 25/09/2017 à 21:08, Bruno a écrit :
> Le 25/09/2017 à 19:51, Cédric Frayssinet a écrit :
>>
>> Bonjour à tous,

Salut Cédric et bienvenu ^^

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

une vraie… drogue

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

Le plus simple pour JOSM est tout de même quand quelqu'un te montre le
fonctionnement.

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

-- 
Dlareg

Les publicités pour les entreprises transnationales ne sont pas des cas
isolés
http://citedelagastro-dijon.com/

La Cité de la gastronomie est un parc à thème
http://www.dlareg.org/post/2014/11/19/Dans-la-cité-de-la-gastronomie-la-publicité-s-affiche




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

[OSM-talk] OSM stats update

[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: [Talk-it] Sito statistiche "Dapal"

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

[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: [Talk-it] Sito statistiche "Dapal"

[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

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

[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: [OSM-talk-fr] Contribution arbres remarquables du Bas-Rhin

[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-cz] rozcestniky

[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: [Talk-it] Sito statistiche "Dapal"

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

[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: [OSM-talk-fr] Présentation

[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: [Talk-us] Recent Aerial Photo Imagery Changes

[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

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

[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: [OSM-talk] Downloading Version 3 of all bus stops in a country

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

[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: [OSM-talk-fr] Présentation

[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: [OSM-talk] Downloading Version 3 of all bus stops in a country

[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

[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

[OSM-talk-fr] Cartopartie : Libre information sur les services de santé, tous acteurs, tous concernés ! jeudi 16 novembre à Digne

[Jean-Christophe Becquet]

Bonjour,

L'ADRETS, en partenariat avec APITUX et avec le soutien de la fondation
AFNIC travaille sur la cartographie participative des services au
public. Dans ce cadre, nous préparons une journée « cartopartie des
services » sur le thème de la santé, jeudi 16 novembre 2017 de 9h à 18h
à Digne.

Il s'agit d'animer un atelier afin d'enrichir OpenStreetMap avec l'offre
de santé sur le territoire puis d'en tirer des cartes et un annuaire.
Les visiteurs pourront parcourir l'atelier juste pour découvrir les
outils et la démarche ou s'installer plus longuement pour contribuer en
étant accompagnés par des experts. De 15h à 16h, une table ronde
rassemblera les participants autour du thème : « Libre information sur
les services de santé, tous acteurs, tous concernés ! ».

Cet événement est hébergé à Digne par le Lycée Pierre Gilles de Gennes
dans le cadre de son Salon domotique santé. Il s'inscrit également dans
la semaine de sensibilisation OSMGEOWEEK qui propose aux contributeurs
partout dans le monde de se regrouper pour créer des cartes avec
OpenStreetMap.

L'ADRETS
http://www.adrets-asso.fr

APITUX
http://www.apitux.com

Cartopartie : Libre information sur les services de santé, tous acteurs,
tous concernés !
http://ferme.animacoop.net/wikis/afnicarto/wakka.php?wiki=CartoSante

OpenStreetMap : un projet collaboratif de cartographie libre
http://www.apitux.org/index.php?2007/08/31/190-openstreetmap-un-projet-collaboratif-de-cartographie-libre

Le salon domotique santé
https://www.bts-fluide-energie-domotique-dbc-pgdg.com/salon-domotique-sante

Agenda du libre
https://www.agendadulibre.org/events/15430

Propager l'info
https://twitter.com/AgendaduLibreFr/status/912563304974909440

Bonne journée

JCB
-- 
Le guide pratique d’usage des logiciels libres dans les administrations
http://www.apitux.org/index.php?2007/07/04/167-le-guide-pratique-dusage-des-logiciels-libres-dans-les-administrations

==APITUX : le choix du logiciel libre==

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

===






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

[Talk-dk] Standardisering af tankstationer i DK

[Michael Andersen]

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.

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.

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

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

[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

[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

[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-fr] Contribution arbres remarquables du Bas-Rhin

[PanierAvide]

Pour de la semi-automatisation, il y a le plugin Conflation de JOSM : 
https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Conflation


Un cas d'usage récent était de pouvoir réaliser des mises à jour de 
données cadastrales. Logiquement ça doit pouvoir aussi s'utiliser sur 
des arbres.


Cordialement,

Adrien.


Le 26/09/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.

Si le cas des 250 arbres est isolé, alors la génération à sens unique
de XML JOSM et son injection après revue humaine est parfaitement
satisfaisante - et tant pis pour les nouvelles versions du fichier des
arbres remarquables du Bas Rhin: la mise à jour aura lieu manuellement.

Si d'autres sources similaires pourraient être exploitées, alors on
peut réfléchir à de l'outillage.

Bon, j'admet un gros biais personnel en faveur de l'industrialisation
lourde et parfois prématurée - mort aux tâches manuelles sans valeur
ajoutée... Même parfois lorsque les automatismes coûtent plus cher que
la prestation humaine - mais c'est tellement plus satisfaisant...

___
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

[David Crochet]

Bonjour


Le 26/09/2017 à 09:57, PIERRE Sylvain a écrit :

il me semble avoir identifié l'obligation de publier préalablement en OpenData 
les données dans le cas d'un import. Est-ce exact?


C'est mieux d'avoir l'information au préalable. J'ai contacté la ville 
de Caen : Sur leur site web, il indique un nombre précis d'arbre. Cela 
voudrait dire /a priori/ qu'ils ont été recensé. Dans l'échange en 
cours, je leur ait dit que la technique, on est capable de faire (format 
de production du fichier), mais qu'eux doivent mettre une licence :


https://twittehttps://twitter.com/Crochetdavid/status/912335352869859328r.com/Crochetdavid/status/912335352869859328
https://twitter.com/Crochetdavid/status/912335352869859328
puis https://twitter.com/Crochetdavid/status/912335393164587009
enfin https://twitter.com/Crochetdavid/status/912409712913735680

Cordialement

--
David Crochet

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

Re: [OSM-talk-ie] Email privacy

[Ken Guest]

yes

You may have noticed before you signed up to this open mailing list
the link to prior postings to the mailing list that does not require a
login to view them.

"""This list provides a forum for discussion those parts of
openstreetmap that are relevant to Ireland. It is not a substitute for
the t...@openstreetmap.org mailing list, but should provide more
localised information for those mapping in Ireland.

To see the collection of prior postings to the list, visit the Talk-ie
Archives."""


caveat emptor jugulum...


On 26 September 2017 at 06:49, Colm Moore  wrote:
> Hi,
>
>
> I note that this mailing list is put on the web here: 
> https://lists.openstreetmap.org/pipermail/talk-ie/2015-July/001272.html
>
>
> This includes email addresses in the format person at example.com
>
>
> Is this appropriate?
>
>
> Colm
>
>
> ---
> Never doubt that a small group of thoughtful, committed citizens can change 
> the world. Indeed, it is the only thing that ever has. Margaret Mead
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie



-- 
http://about.me/kenguest/

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

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

[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] Downloading Version 3 of all bus stops in a country

[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] Adding wikidata tags to the remaining objects with only wikipedia tag

[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-fr] Contribution arbres remarquables du Bas-Rhin

[Jean-Marc Liotier]

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.

Si le cas des 250 arbres est isolé, alors la génération à sens unique
de XML JOSM et son injection après revue humaine est parfaitement
satisfaisante - et tant pis pour les nouvelles versions du fichier des
arbres remarquables du Bas Rhin: la mise à jour aura lieu manuellement.

Si d'autres sources similaires pourraient être exploitées, alors on
peut réfléchir à de l'outillage.

Bon, j'admet un gros biais personnel en faveur de l'industrialisation
lourde et parfois prématurée - mort aux tâches manuelles sans valeur
ajoutée... Même parfois lorsque les automatismes coûtent plus cher que
la prestation humaine - mais c'est tellement plus satisfaisant...

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

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

[marc marc]

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

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

[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

[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

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

[PIERRE Sylvain]

Merci pour tous ces retours.
Si effectivement il n’est pas nécessaire de mettre en œuvre une procédure 
d’import (que j’avais identifié comme assez lourde) et que JOSM + greffon 
todolist permettent de faire le job de manière intelligente alors ok.

Merci pour la proposition de générer un fichier OSM, mais j’aimerais pouvoir 
acquérir qq compétences dans ce domaine. J’imagine qu’il y a des pages sur ce 
sujet dans le wiki ?

Les données sont à nous.

SP

De : Jo [mailto:winfi...@gmail.com]
Envoyé : mardi 26 septembre 2017 11:03
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Contribution arbres remarquables du Bas-Rhin

Pierre,
Je pense aussi qu'il n'est pas vraiment nécessaire de faire tous les pas d'un 
import.
La question la plus importante est la license. Ces données sont à vous?
Si vous m'envoyez une liste avec tous les détails, je veux bien les convertir 
en fichier OSM et créer une petite vidéo démontrant comment s'y prendre pour 
les ajouter à l'aide du greffon todo-list avec JOSM.
Jo

2017-09-25 16:39 GMT+02:00 PIERRE Sylvain 
>:
Bonjour,

Le département du Bas-Rhin a initié depuis 5 ans un inventaire des arbres 
remarquables.
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.

Après avoir parcouru les ressources suivantes :
http://openstreetmap.fr/contribuer
http://wiki.openstreetmap.org/wiki/FR:Guide_du_d%C3%A9butant
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree
http://wiki.openstreetmap.org/wiki/Import/Guidelines

nos interrogations sont les suivantes :

• Pouvons-nous contribuer à OSM sur ce périmètre, et si oui comment ?

• Faut-il privilégier la saisie individuelle de chaque arbre ? Ou bien 
l’import ?

D’avance merci



→  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:image001.jpg@01D336BA.24A27580]

 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



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

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

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

[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-fr] Contribution arbres remarquables du Bas-Rhin

[Jo]

Pierre,

Je pense aussi qu'il n'est pas vraiment nécessaire de faire tous les pas
d'un import.

La question la plus importante est la license. Ces données sont à vous?

Si vous m'envoyez une liste avec tous les détails, je veux bien les
convertir en fichier OSM et créer une petite vidéo démontrant comment s'y
prendre pour les ajouter à l'aide du greffon todo-list avec JOSM.

Jo

2017-09-25 16:39 GMT+02:00 PIERRE Sylvain :

> Bonjour,
>
>
>
> Le département du Bas-Rhin a initié depuis 5 ans un inventaire des arbres
> remarquables.
>
> 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.
>
>
>
> Après avoir parcouru les ressources suivantes :
>
> http://openstreetmap.fr/contribuer
>
> http://wiki.openstreetmap.org/wiki/FR:Guide_du_d%C3%A9butant
>
> http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree
>
> http://wiki.openstreetmap.org/wiki/Import/Guidelines
>
>
>
> nos interrogations sont les suivantes :
>
> · Pouvons-nous contribuer à OSM sur ce périmètre, et si oui
> comment ?
>
> · Faut-il privilégier la saisie individuelle de chaque arbre ? Ou
> bien l’import ?
>
>
>
> D’avance merci
>
>
>
>
>
>
>
> *→*  *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*
>
> 
>
>  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
>
>
>
> ___
> 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] Adding wikidata tags to the remaining objects with only wikipedia tag

[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-fr] Présentation

[Jo]

Bienvenu Cédric!

Marc,

Qu'est-ce qui manque? Il n'est pas possible de faire cela en utilisant F3?

Jo

2017-09-26 10:08 GMT+02:00 marc marc :

> Le 25. 09. 17 à 19:51, Cédric Frayssinet a écrit :
> > Nouveau sur cette liste, je me présente rapidement.
> Bonjour et bienvenu !
>
> > J'avoue, je n'utilise pas encore JOSM
> Si c'est ton souhait, je trouve Josm aussi facile que iD.
> la seule chose qu'il lui manque, c'est la recherche
> d'un tag à partir d'un mot-clef.
> Pour cela, il suffit d'ouvrir la page du wiki.
> > https://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%
> A9ments_cartographiques
>
> Mais pour le reste, je trouve Josm bien plus agréable à utiliser que iD
>
> Cordialement,
> Marc
> ___
> 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

[Vincent de Château-Thierry]

Bonjour Sylvain,

> 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", avec la lourdeur et la mauvaise presse 
de ce genre de manips. Le passage en revue de 250 objets pour identifier de 
possibles doublons avec les arbres existants, et envisager la consolidation des 
données, est vu le volume assez aisé. Un outil de contribution comme JOSM, avec 
son greffon 'ToDo List' [1] rendent ce passage en revue efficace, sans 
comparaison avec la conception d'un outil qui ferait la même chose.

vincent

[1] : https://wiki.openstreetmap.org/wiki/JOSM/Plugins/TODO_list

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