Re: [OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[Jo]

You can also use OSM inspector to find untagged ways:

http://tools.geofabrik.de/osmi/?view=tagging=-1.25144=5.12425=13=0.63=ways_without_tags

and it's of course the better option instead of adding load to Overpass API.

Polyglot

2017-10-30 2:47 GMT+01:00 Jo :

> Untagged ways in a bbox:
>
> https://overpass-turbo.eu/s/sFU
>
> way({{bbox}})(if:count_tags()==0)->.w1;
> rel(bw.w1);way(r)->.w2;
> (.w1; - .w2;);
> (._; >;);
> out meta;
>
> Michael beat me to the answer for the other query. Way too many comes near
> as an answer.
>
> Jo
>
>
> 2017-10-30 2:01 GMT+01:00 john whelan :
>
>> Many of the untagged ways are from JOSM and that warns before uploading
>> as well.
>>
>> Out of curiosity does any one have a count of the number of untagged ways
>> and area=yes in the database?
>>
>> Thanks John
>>
>> On 29 Oct 2017 8:53 pm, "Bryan Housel"  wrote:
>>
>>> Haha I promise I won’t be offended.  I welcome the criticism - this is
>>> part of working on something that matters to a lot of people.
>>>
>>> Anyway, iD already does train the user in the walkthrough how to assign
>>> tags, and iD does warn the user on the save screen if they are uploading
>>> untagged features.
>>>
>>> So, what would you prefer iD do.. Just not upload untagged things?  We
>>> could do this, and I don’t have any strong opinion one way or another.
>>>
>>> In the past, the thinking has been that it’s better to accept an
>>> imperfect contribution than to turn away an imperfect contributor.   The
>>> map is used for a lot of things these days - so maybe we should rethink
>>> this as a community how we handle obviously bad edits.
>>>
>>> Bryan
>>>
>>>
>>>
>>>
>>> On Oct 29, 2017, at 7:23 PM, Jo  wrote:
>>>
>>> Yes, it's amazing that after all these years of reporting it, that BUG
>>> in iD still hasn't been resolved. But don't dare to complain, we might
>>> offend Bryan.
>>>
>>> Polyglot
>>>
>>> 2017-10-29 23:47 GMT+01:00 Mark Wagner :
>>>
 On Sun, 29 Oct 2017 22:15:18 +0200
 Safwat Halaby  wrote:

 > - Adding closed ways with area=yes instead of building=yes, or with no
 > tags at all

 A closed way with "area=yes" is a *very* common newbie mistake with iD:
 the user traced an area, then forgot to tag it, or didn't realize they
 needed to apply additional tags.

 --
 Mark

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

>>>
>>> ___
>>> talk mailing list
>>> talk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk
>>>
>>>
>>>
>>> ___
>>> 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-au] BYO drinks at restaurant

[Warin]

Possibly
fee:corkage=yes?

On 30-Oct-17 02:20 PM, Ben Kelley wrote:
To be honest, I don't think this is useful, but I guess that is up to 
the mapper.


 - Ben.

On 30/10/17 14:04, Nick Hocking wrote:
If byo=yes, then it would be useful to know if corkage is charged, 
and if so, how much.



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




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

Re: [OSM-talk] Scientific paper on "Information Seeding"

[Clifford Snow]

On Mon, Oct 9, 2017 at 4:07 PM, Christoph Hormann  wrote:

>
> The analysis and the observations coming from it look pretty solid.  I
> am not fully convinced by the interpretation of the reasons lying
> largely in contributors taking 'ownership' of the data they contribute.
> This would in my eyes - at least if meant in terms of individual
> ownership - require the original contributors at the beginning to
> continue to be significant in terms of overall contribution volume over
> the whole time span analyzed.  This seems rather unlikely considering
> the active contributor turnover we have in general
> (https://wiki.openstreetmap.org/wiki/File:Active_contributors_year.png).
>

Christoph,
As Simon said, I believe there may be some validity to Abhishek Nagaraj's
findings on ownership.  It's why so many people watch edits in their area.
They are quick to challenge poor edits in their watch area. I believe they
have a sense of ownership in the area. It's an attribute that would be nice
to encourage. I think of it more in terms of stewardship rather than
ownership, but either way, OSM benefits.

Clifford


-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Scientific paper on "Information Seeding"

[Clifford Snow]

Frederik,
Abhishek Nagaraj, the author of the study you mentioned, presented [1] his
findings at the SotM-US in Boulder. I had a chance to ask Abhishek about
his research findings. What he said is that how the import is designed has
a lot to due with how they impact subsequent edits. In the case of the
TIGER import, the counties with poor data [1], suffered. Counties with
better (I'd never say good) did not. The poor TIGER counties saw few road
attributes, like surface= tags, added.

In contract, after the Building and Address import in Seattle, users
commented how much easier it was to add poi information. The import does
not seem to have impact user contributions. In fact Seattle has a very
active OSM community. Many factors go into why Seattle is successful. The
high tech presence in the area, the OSM Meetup group, the active OSGEO
community, and the communities willingness to get involved. The
building/address import was just one small part of the equation.

>From what I took away from the study is that imports need to be well
thought out and executed.

I encourage everyone to watch Abhishek Nagaraj presentation [1] - and I'm
not just saying that I'm mentioned. 

[1] https://2017.stateofthemap.us/program/quasi-experimental-research.html
[2] Some counties data had been cleaned up prior to publishing while others
were not.

Clifford

On Mon, Oct 9, 2017 at 3:10 PM, Frederik Ramm  wrote:

> Hi,
>
> today I was pointed to a recent, open-access scientific paper called
> "Information Seeding and Knowledge Production in Online Communities:
> Evidence from OpenStreetMap". This open-access paper is available here
>
> https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3044581
>
> In the context of armchair mapping, but especially of data imports (and
> recently, machine-generated OSM data) there's always been the discussion
> between those who say "careful, too much importing will hurt the growth
> of a local community", and others who say "this import is going to
> kick-start a local community, let's do it!"
>
> Until now this has been a rather un-proven matter of belief, and the
> general mood is usually in favour of a quick build-up of data (through
> remote mapping, importing, or machine learning) instead of a
> take-it-slow approach that would wait for a community to form and take
> matters into their own hands.
>
> The paper quoted above uses OSM as a research object and finds that in
> certain ways imports in OSM have indeed harmed community growth. The
> paper attempts to provide insights helpful for all kinds of
> user-generated knowledge projects (not necessarily OSM), and
> draws the following conclusion:
>
> "While information seeding could be useful to encourage the production
> of distant forms of follow-on knowledge, it might demotivate and
> under-provide more mundane and incremental follow-on information.
> Accordingly, if managers are interested in leveraging pre-existing
> information to spur the development of online communities, they might be
> better served by withholding some pre-existing information and provide
> community members with some space to create knowledge from scratch—even
> if such knowledge already exists in an external source. This policy allows
> community members to become invested in the community and develop
> ownership over the knowledge."
>
> 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
>



-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [talk-au] BYO drinks at restaurant

[Ben Kelley]

To be honest, I don't think this is useful, but I guess that is up to 
the mapper.


 - Ben.

On 30/10/17 14:04, Nick Hocking wrote:
If byo=yes, then it would be useful to know if corkage is charged, and 
if so, how much.



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

Re: [talk-au] BYO drinks at restaurant

[Nick Hocking]

If byo=yes, then it would be useful to know if corkage is charged, and if
so, how much.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[Jo]

Untagged ways in a bbox:

https://overpass-turbo.eu/s/sFU

way({{bbox}})(if:count_tags()==0)->.w1;
rel(bw.w1);way(r)->.w2;
(.w1; - .w2;);
(._; >;);
out meta;

Michael beat me to the answer for the other query. Way too many comes near
as an answer.

Jo


2017-10-30 2:01 GMT+01:00 john whelan :

> Many of the untagged ways are from JOSM and that warns before uploading as
> well.
>
> Out of curiosity does any one have a count of the number of untagged ways
> and area=yes in the database?
>
> Thanks John
>
> On 29 Oct 2017 8:53 pm, "Bryan Housel"  wrote:
>
>> Haha I promise I won’t be offended.  I welcome the criticism - this is
>> part of working on something that matters to a lot of people.
>>
>> Anyway, iD already does train the user in the walkthrough how to assign
>> tags, and iD does warn the user on the save screen if they are uploading
>> untagged features.
>>
>> So, what would you prefer iD do.. Just not upload untagged things?  We
>> could do this, and I don’t have any strong opinion one way or another.
>>
>> In the past, the thinking has been that it’s better to accept an
>> imperfect contribution than to turn away an imperfect contributor.   The
>> map is used for a lot of things these days - so maybe we should rethink
>> this as a community how we handle obviously bad edits.
>>
>> Bryan
>>
>>
>>
>>
>> On Oct 29, 2017, at 7:23 PM, Jo  wrote:
>>
>> Yes, it's amazing that after all these years of reporting it, that BUG in
>> iD still hasn't been resolved. But don't dare to complain, we might offend
>> Bryan.
>>
>> Polyglot
>>
>> 2017-10-29 23:47 GMT+01:00 Mark Wagner :
>>
>>> On Sun, 29 Oct 2017 22:15:18 +0200
>>> Safwat Halaby  wrote:
>>>
>>> > - Adding closed ways with area=yes instead of building=yes, or with no
>>> > tags at all
>>>
>>> A closed way with "area=yes" is a *very* common newbie mistake with iD:
>>> the user traced an area, then forgot to tag it, or didn't realize they
>>> needed to apply additional tags.
>>>
>>> --
>>> Mark
>>>
>>> ___
>>> talk mailing list
>>> talk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk
>>>
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>>
>>
>> ___
>> 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] Sudden influx of bad HOTosm edits in West Bank

[Michael Bemmerl]

Pierre Béland schrieb:
> Bryan Housel wrote:
> > Many of the untagged ways are from JOSM and that warns before
> uploading as well.
> and
> John Whelan wrote:
> > Many of the untagged ways are from JOSM and that warns before
> uploading as well.
>
>
> It is always possible to query Overpass and find such problems.

This query returned nearly 21.000 ways in Western Europe:

way["area"="yes"]({{bbox}})(if:count_tags() == 1);

Regards,
Michael

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

Re: [OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[Pierre Béland]

Bryan Housel wrote:> Many of the untagged ways are from JOSM and that warns 
before uploading as well.and
John Whelan wrote:> Many of the untagged ways are from JOSM and that warns 
before uploading as well.

It is always possible to query Overpass and find such problems.
But if applications such as iD and JOSM did add to the Changesets metadata a 
Warning tag, this could be used by applications such as OSMCHA to filter 
changesets.  
Something like warning=Orphan nodes; no tags; etc.
 
Pierre 

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

Re: [OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[Jo]

Next to the buttons for point, line and area, add a button to add
rectangular buildings. Let user click 3 times instead of 5 and tag it as
building=yes.

Polyglot

2017-10-30 1:50 GMT+01:00 Bryan Housel :

> Haha I promise I won’t be offended.  I welcome the criticism - this is
> part of working on something that matters to a lot of people.
>
> Anyway, iD already does train the user in the walkthrough how to assign
> tags, and iD does warn the user on the save screen if they are uploading
> untagged features.
>
> So, what would you prefer iD do.. Just not upload untagged things?  We
> could do this, and I don’t have any strong opinion one way or another.
>
> In the past, the thinking has been that it’s better to accept an imperfect
> contribution than to turn away an imperfect contributor.   The map is used
> for a lot of things these days - so maybe we should rethink this as a
> community how we handle obviously bad edits.
>
> Bryan
>
>
>
>
> On Oct 29, 2017, at 7:23 PM, Jo  wrote:
>
> Yes, it's amazing that after all these years of reporting it, that BUG in
> iD still hasn't been resolved. But don't dare to complain, we might offend
> Bryan.
>
> Polyglot
>
> 2017-10-29 23:47 GMT+01:00 Mark Wagner :
>
>> On Sun, 29 Oct 2017 22:15:18 +0200
>> Safwat Halaby  wrote:
>>
>> > - Adding closed ways with area=yes instead of building=yes, or with no
>> > tags at all
>>
>> A closed way with "area=yes" is a *very* common newbie mistake with iD:
>> the user traced an area, then forgot to tag it, or didn't realize they
>> needed to apply additional tags.
>>
>> --
>> Mark
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[john whelan]

Many of the untagged ways are from JOSM and that warns before uploading as
well.

Out of curiosity does any one have a count of the number of untagged ways
and area=yes in the database?

Thanks John

On 29 Oct 2017 8:53 pm, "Bryan Housel"  wrote:

> Haha I promise I won’t be offended.  I welcome the criticism - this is
> part of working on something that matters to a lot of people.
>
> Anyway, iD already does train the user in the walkthrough how to assign
> tags, and iD does warn the user on the save screen if they are uploading
> untagged features.
>
> So, what would you prefer iD do.. Just not upload untagged things?  We
> could do this, and I don’t have any strong opinion one way or another.
>
> In the past, the thinking has been that it’s better to accept an imperfect
> contribution than to turn away an imperfect contributor.   The map is used
> for a lot of things these days - so maybe we should rethink this as a
> community how we handle obviously bad edits.
>
> Bryan
>
>
>
>
> On Oct 29, 2017, at 7:23 PM, Jo  wrote:
>
> Yes, it's amazing that after all these years of reporting it, that BUG in
> iD still hasn't been resolved. But don't dare to complain, we might offend
> Bryan.
>
> Polyglot
>
> 2017-10-29 23:47 GMT+01:00 Mark Wagner :
>
>> On Sun, 29 Oct 2017 22:15:18 +0200
>> Safwat Halaby  wrote:
>>
>> > - Adding closed ways with area=yes instead of building=yes, or with no
>> > tags at all
>>
>> A closed way with "area=yes" is a *very* common newbie mistake with iD:
>> the user traced an area, then forgot to tag it, or didn't realize they
>> needed to apply additional tags.
>>
>> --
>> Mark
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
>
> ___
> 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] Sudden influx of bad HOTosm edits in West Bank

[Bryan Housel]

Haha I promise I won’t be offended.  I welcome the criticism - this is part of 
working on something that matters to a lot of people.

Anyway, iD already does train the user in the walkthrough how to assign tags, 
and iD does warn the user on the save screen if they are uploading untagged 
features.  

So, what would you prefer iD do.. Just not upload untagged things?  We could do 
this, and I don’t have any strong opinion one way or another.  

In the past, the thinking has been that it’s better to accept an imperfect 
contribution than to turn away an imperfect contributor.   The map is used for 
a lot of things these days - so maybe we should rethink this as a community how 
we handle obviously bad edits.

Bryan




> On Oct 29, 2017, at 7:23 PM, Jo  wrote:
> 
> Yes, it's amazing that after all these years of reporting it, that BUG in iD 
> still hasn't been resolved. But don't dare to complain, we might offend Bryan.
> 
> Polyglot
> 
> 2017-10-29 23:47 GMT+01:00 Mark Wagner  >:
> On Sun, 29 Oct 2017 22:15:18 +0200
> Safwat Halaby > wrote:
> 
> > - Adding closed ways with area=yes instead of building=yes, or with no
> > tags at all
> 
> A closed way with "area=yes" is a *very* common newbie mistake with iD:
> the user traced an area, then forgot to tag it, or didn't realize they
> needed to apply additional tags.
> 
> --
> Mark
> 
> ___
> talk mailing list
> talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [talk-au] BYO drinks at restaurant

[Phil (The Geek) Wyatt]

Looks like a few folks have used byo=yes and others have added the details in a 
note or the name.

 

https://taginfo.openstreetmap.org/search?q=byo#values 
  

 

Very few tags overall which is surprising

 

Cheers - Phil

 

From: Graeme Fitzpatrick [mailto:graemefi...@gmail.com] 
Sent: Monday, October 30, 2017 11:34 AM
To: OSM
Subject: [talk-au] BYO drinks at restaurant

 

G'day all

 

Just adding a Pizza & Pasta restaurant that is BYO drinks.

 

Can't see any option


Thanks

 

Graeme

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

Re: [talk-au] BYO drinks at restaurant

[Ben Kelley]

I can't see anything suitable on the amenity=restaurant page.

In some sense, I suspect this is a fairly Australian thing.

I wonder about a tag related to the service of alcohol at that 
restaurant. e.g. the description for Restaurant says "A restaurant is a 
place selling full meals served by waiters, generally formal with 
sit-down facilities and *often licensed (where allowed) to sell 
alcoholic drinks*."


I wonder about a tag that indicates if alcohol is available. Can you buy 
alcoholic drinks at this restaurant? Can you bring your own alcoholic 
drinks? These two are not mutually exclusive though.


These both seem like useful things to me. (Although that said, I have 
never used OSM to research where to go for dinner...)



 - Ben.


On 30/10/17 11:33, Graeme Fitzpatrick wrote:

G'day all

Just adding a Pizza & Pasta restaurant that is BYO drinks.

Can't see any option
Thanks

Graeme


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

[talk-au] BYO drinks at restaurant

[Graeme Fitzpatrick]

G'day all

Just adding a Pizza & Pasta restaurant that is BYO drinks.

Can't see any option
Thanks

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

Re: [OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[Jo]

Yes, it's amazing that after all these years of reporting it, that BUG in
iD still hasn't been resolved. But don't dare to complain, we might offend
Bryan.

Polyglot

2017-10-29 23:47 GMT+01:00 Mark Wagner :

> On Sun, 29 Oct 2017 22:15:18 +0200
> Safwat Halaby  wrote:
>
> > - Adding closed ways with area=yes instead of building=yes, or with no
> > tags at all
>
> A closed way with "area=yes" is a *very* common newbie mistake with iD:
> the user traced an area, then forgot to tag it, or didn't realize they
> needed to apply additional tags.
>
> --
> Mark
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] weeklyOSM #379 2017-10-17-2017-10-23

[Tobias Knerr]

On 28.10.2017 12:06, Andrew Hain wrote:
> His behaviour over the past years makes him a contributor of net
> negative value.

I have to disagree here. He's probably the single most active wiki
contributor, and is also performing a lot of useful maintenance work
that no one else would bother doing.

His communication style needs to improve a lot, no doubt about that. But
even so, his contributions are still a net positive for OSM.

This does not mean that he should be exempt from the rules, of course.
To the contrary: What I would hope for is consistent enforcement of the
rules, with gradually increasing penalties. Jumping straight from spotty
enforcement to a permanent ban, though, seems wasteful and needlessly cruel.

Tobias

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

Re: [OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[Mark Wagner]

On Sun, 29 Oct 2017 22:15:18 +0200
Safwat Halaby  wrote:

> - Adding closed ways with area=yes instead of building=yes, or with no
> tags at all

A closed way with "area=yes" is a *very* common newbie mistake with iD:
the user traced an area, then forgot to tag it, or didn't realize they
needed to apply additional tags.

-- 
Mark

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

Re: [OSM-talk] weeklyOSM #379 2017-10-17-2017-10-23

[Peter Barth]

Hi,

Andrew Hain schrieb:
> It is now time to talk about banning Verdy p from the wiki permanently.
 
as someone involved, I wanted to note that *this* actually doesn't make
a good case to ban him.
 
Every second OSM regulars table someone complaints about him. There are
a tons of valid complaints, besides simplest edits to one page being 
scattered across tens of changes, no edit comments, tl-dr-discussions,...
 
So there should be either a way to make him work by the rules by e.g.
giving him concrete constraints. Or we should use one of the many other 
better cases to block him. 

Peda

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

Wochennotiz Nr. 379 17.10.2017–23.10.2017

[Wochennotizteam]

Hallo,

die Wochennotiz Nr. 379 mit vielen wichtigen Neuigkeiten aus der 
OpenStreetMap-Welt ist da:

http://blog.openstreetmap.de/blog/2017/10/wochennotiz-nr-379/

Viel Spaß beim Lesen!
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Wochennotiz Nr. 379 17.10.2017–23.10.2017

[Wochennotizteam]

Hallo,

die Wochennotiz Nr. 379 mit vielen wichtigen Neuigkeiten aus der 
OpenStreetMap-Welt ist da:

http://blog.openstreetmap.de/blog/2017/10/wochennotiz-nr-379/

Viel Spaß beim Lesen!
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fehler mit Nominatim

[Walter Nordmann]

Hi Georg,


Am 29.10.2017 um 21:22 schrieb Georg Feddern:


Für den Status einer administrativen Einheit Ortsbezirk 
(admin_level=10) Kernstadt steht es also Aussage gegen Aussage ...


jo, das stimmt. Es könnte durchaus sein, dass diese "Administrative" 
Grenze als solche keine formale Berechtigung hat - das kann ich als 
Aussenstehender (Hesse) nicht beurteilen.
Nichtsdestotrotz würde auch ich den Ortsteil "Kernstadt" zu Zwecken 
der eindeutigeren Zuordnung in der Ebene 9/10 erhalten.
Allerdings ist ganz Daun(8) mit insgesamt 9 "Ortsteilen" als AL10 
vollständig erfasst.


<%21[rettungswache_daun4]%28https://wambachers-osm.website/images/osm/snaps_2017/rettungswache_daun4.png%29>https://wambachers-osm.website/images/osm/snaps_2017/rettungswache_daun4.png

Jetzt würde ich gerne mal die Begründung hören, wieso gerade die 
Kernstadt gelöscht wurde aber die anderen 8 Ortsteile nicht ;)


ps: Übrigens bin ich mir sicher, dass spätestens am Montag irgend ein 
Kollege die fehlende Grenze aufgrund der nächsten Missing 
Boundaries-Auswertung reanimiert hätte. 
https://wambachers-osm.website/index.php/10-osm-reports/1067-countries-compare-2017-10-29


gruss
walter

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

Re: [Talk-it] ruota idraulica di una segheria

[Volker Schmidt]

Una segheria che è operata con acqua secondo Wikipedia è un tipo di
watermill. Il termine inglese "sawmill" è una segheria indipendentemente
del tipo di "motore".
Quindi potresti utilizzare:
building=yes
disused:man_made=watermill
historic=sawmill
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] passage du code FANTOIR de 11 à 10 chiffres

[Philippe Verdy]

Le 29 octobre 2017 à 22:16, marc marc  a écrit :

> Tu n'as pas vu le problème du 4 en 3ieme position dans les ref fantoir
> 7540093510R et 7541093510F, ce n'est pas le code direction.
>
> en partant de
> https://www.data.gouv.fr/fr/datasets/fichier-fantoir-des-
> voies-et-lieux-dits/
>
> cela ne change rien, cela renseigne heureusement les mêmes codes fantoir
>
> Mais on a trouvé la réponse dans le pdf officiel qui dit "le code
> direction est égal à 0, à l'exception de quatre départements:Paris (754
> à 758), les Bouches-du-Rhône (131, 132), le Nord (591, 592) et les
> Hauts-de-Seine (921, 922). »
> ils utilisent des codes départements "tordu"
>
> donc dans le détail
> 7540093510R et 7541093510F sont divisée en
> 754 pseudo-département
> 0 ou 1 code direction (qu'on vire pour osm)
> 09 arrondissement
> 3510 rivoli
> R ou F code contrôle
>

Dans le détail moi je comprend ceci:


> 75 département
> 4 code direction (qu'on vire dans OSM)
> 009 ou 109 arrondissement (à unifier vers le code INSEE de
> l'arrondissement 109 et non le code postal 009)
> 3510 rivoli
> R ou F code contrôle
>

Dans tous les cas, c'est toujours le 3e chiffre du code DGFiP à 11 chiffre
qu'on vire. Le problème c'est plutôt le 4e chiffre des communes à
arrondissements (0 ou 1) qui n'est pas cohérent...

La code de contrôle en revanche est calculé sur le code entier (code
direction inclu, et avec le code commune ou arrondissement communal
indiqué; je suppose que si ces codes d'arrondissement ne sont pas unifiés
c'est à cause d'une cuisine interne de la DGFiP qui a revu la carte de ses
directions locales et a pu diviser un même arrondissement sur deux
directions différentes à un moment donné, même si la dernière direction est
la numéro 4. Ou bien il y a pu y a voir des sous-directions aussi à Paris
et ils ont emprunté encore un chiffre inutilisé dans le code
d'arrondissement communal).

Il y a peut-être une origine aussi à chercher du côté de l'ancienne
administration de Paris (avant la création de la Mairie de Paris et la
relégation des mairies d'arrondissements à un rôle essentiellement exécutif
au sein de la municipalité, mais avant les mairies d'arrondissement
pouvaient avoir des secteurs distingués selon les quartiers
admisnitratrifs, ici pour le 9e les quartiers Saint-Georges
 (33),
Chaussée-d'Antin
 (34),
Faubourg-Montmartre
 (35) et
Rochechouart  (36).

Alors si on supprime le code direction, est-ce que la clé de contrôle est
encore signifiante? Je pense qu'au moins à titre de vérification on peut le
garder... si c'est stable. je me demande aussi si la DGFiP ne va pas
réattribuer d'autres numéros en jouant sur le 4e caractère dans le cas où
une voie est subdivisée et ne correspond plus entièrement à son ancien
tracé et ce changement était également visible dans la clé. Cependant le
FANTOIR actuel doit avoir oublié ce système grace aux mises à jour
annuelles et par le fait que le fichier date chaque entrée individuellement
dans un champ séparé (je ne sais pas si cela a toujours été le cas). Ou
bien il y a pu y avoir des erreurs lors de la transition du RIVOLI au
FANTOIR lors de la fusion des données entre les différentes directions.

Le dernier mystère à éclaircir: comment est calculé la clé de contrôle
réellement ? la doc dit que c'est une lettre de l'alphabet sans O,I,Q (donc
calculé avec modulo 23, et on voit d'une différence de 1 sur le dernier
chiffre de la voie donne une différence de 2 lettres sur la clé, ce qui
semble indiquer une variante améliorée du LUHN avec ses multiplicateurs
alternant 1 et 2 selon la position, mais avec un modulo 23 premier et plus
précis, au lieu de 10 non premier).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[Safwat Halaby]

On Sun, 2017-10-29 at 20:13 +0100, Blake Girardot HOT/OSM wrote:
> Greetings,
> 
> I SomeoneElse mentioned this in our HOT IRC channel.
> 
> I have already asked the project creator to take a look.
> 
> But, are you sure they are bad edits? did you use the 2016 imagery
> specified in the mapping projet?
> 
> For example, change set 53330616, the first one i randomly looked at
> from you list looks like bad editing until you use the 2016 imagery,
> please see the linked to two images below, one with Bing/DG Premium
> (they
> look the same) and one with the imagery supplied with the project.
> 
> So, please let us not rush to revert if you are not using the
> proper imagery.
> 
> As I said, I will or someone else from HOT will look into it further,
> thank you very much for bringing it to our attention, as well as the
> other issues you pointed out, which I have not had a chance to look
> at
> yet.
> 
> https://screenpresso.com/=l5lhb (old bing)
> 
> https://screenpresso.com/=TPYpg (new aerial)

I apologize for spamming the list with multiple split messages. Had
some technical issues. Last message in the series:

I'm afraid I suspect you're not using QA tools properly. Specifically
in JOSM, click the MIDDLE button to to reveal old buildings buried
beneath the newer buildings.

Also, JOSM will not show you when the users deleted buildings and then
re-added them. You'll only see the new buildings.

Also, these are not your typical newbie errors.

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

Re: [OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[Andy Townsend]

On 29/10/2017 21:33, Safwat Halaby wrote:

User "Andrew" added things like "world's biggest refrigerator", "WHEEL
OF FORTUNE", "ANDREWS BIGGEST CAR", "Concrete Thing", etc.


For completeness, http://overpass-turbo.eu/s/sFM shows "Andrew's Dream Car".

Reverting edits such as this makes sense to me.

Best Regards,
Andy


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

Re: [OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[Safwat Halaby]

On Sun, 2017-10-29 at 20:10 +0100, Blake Girardot HOT/OSM wrote:
> But, are you sure they are bad edits? did you use the 2016 imagery
> specified in the mapping projet?
> 
> For example, change set 53330616, the first one i randomly looked at
> from you list looks like bad editing until you use the 2016 imagery,
> please see the attached two images, one with Bing/DG Premium (they
> look the same) and one with the imagery supplied with the project.

This point has been repeated so I'll say one last time that this has
nothing to do with imagery alignment. It has to do with destroying
previous buildings and re-adding them, or adding new buildings on top
of them without destroying them, or other various weird edits.

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

Re: [OSM-talk] Woods vs Forests

[Warin]

On 30-Oct-17 01:16 AM, Tobias Knerr wrote:

On 27.10.2017 00:49, Dave F wrote:

The woods/forest problem is one of the worst tagging cock-ups in OSM.

Indeed. The current mess is especially disappointing because it hasn't
always been that way: The status quo is the result of an attempt to
"improve" the tagging years ago.

 From my point of view, it's plainly obvious that there should be only
one main tag instead of two.

Details on whether the area is used for forestry, whether it is in a
"natural" state (whatever that means), or other such information can be
gathered in addition to that main tag. Gathering that secondary
information should not be a requirement for being able to map the
forest/wood in the first place.


all areas of trees should
be primarily tagged as natural=wood. As with other entities, any further
details which gives clarity should be provided in sub-tags.

That would work nicely as far as I'm concerned.



And then when the trees are harvested in a forestry operation the tag 
natural=wood could be removed with the result that the land use would be lost..
until such time as the tress grow again then the natural=wood could be 
reintroduced, but then the land use would have to be rediscovered and then 
retagged.

At the moment landuse is a separate main tag and is not subservient to another 
tag. That should remain.

I see that some might see a necessity of tagging tree areas with both 
landuse=forest and natural=wood.

However the one does not imply the other, to the extend that I only tag the 
landuse=forest and leave off the natural=wood.

Then there may be others who see natural=wood and think that their area of 
trees are not natural by their definition so falsely use landuse=foresty under 
the impression that any tree are that is 'managed' is suitable for 
landuse=forest.

Solutions?

For the landuse=forest problem?

A) ?
Change the definition of landuse=forest to exclude the word 'managed',
 emphasise the use for the production of goods for human use
e.g. the base material for the production of paper, guitars, floor 
boards,furniture, house frames etc

Some will object to the change of meaning of such a 'frequently used tag', no 
mater how confusing it may be.

B) ?
Alternative - depreciate landuse=forest and introduce a clearly defined 
landuse=forestry that only includes tree areas that produce base material for 
human use.

C) ? others

For the natural=wood problem?

A) ?
Depreciate natural=wood and introduce landcover=trees.

B) ?



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

Re: [OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[Safwat Halaby]

On Sun, 2017-10-29 at 22:24 +0100, Blake Girardot wrote:
> Safwat,
> 
> You are not helping things by unilaterally reverting things and
> accusing people of vandalism after you asked HOT to look into it.
> 
> At this point all I have seen from your first list was some newbie
> edits with some newbie mistakes and some stuff that looked totally
> fine when using the correct imagery.
> 
> and before you started reverting all of the andrew users work, I saw
> decent mapping and bad tagging from a new mapper. clearly not
> vandalism.
> 
> Granted I am not the best at reviewing things by changeset so I might
> have missed something, that is totally possible.
> 
> At this point I am going to stop looking into it since you have
> decided to take matters into your own hands with your own solutions.
> 
> Regards,
> 
> Blake
> 
> 
> On Sun, Oct 29, 2017 at 9:15 PM, Safwat Halaby 
> wrote:
> > 
> > Due to a mailing client config error, I'm unsure if I sent my
> > messages privately or to the list (or at all). At the risk of
> > repeating
> > myself:
> > 
> > The problems are not related to Imagery at all. They're blatantly
> > obvious mapping issues like:
> > - removing things and re-adding them for no apparent reason
> > - Adding buildings on top of pre-existing buildings
> > - Adding closed ways with area=yes instead of building=yes, or with
> > no
> > tags at all
> > - Intentional vandalism in some cases.
> > 
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> 
> 
> 


Dear blake, I'm afraid you're misunderstanding this.

I've not touched anything since contacting the DWG. I've done exactly 2
reverts prior to contacting them.

Revert 1:

The user has added duplicate buildings on top of already existing
buildings, except that those duplicate buildings had no building=yes
tag. I have not accused that user of vandalism and simply reverted. I
then realized this is not an isolated case, so left things for the DWG.

https://www.openstreetmap.org/changeset/53347357

Revert 2:
User "Andrew" added things like "world's biggest refrigerator", "WHEEL
OF FORTUNE", "ANDREWS BIGGEST CAR", "Concrete Thing", etc. This is
blatantly obvious, high priority, destructive vandalism. Sure, the user
may have done some good changes in between, but why should I bother
spending time bisecting the edits of a vandalist? In cases like this,
you revert and ask questions later, and perhaps later extract the good
bits if you've got the time to work through the junk.

https://www.openstreetmap.org/changeset/53347778

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

Re: [OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[Blake Girardot]

Safwat,

You are not helping things by unilaterally reverting things and
accusing people of vandalism after you asked HOT to look into it.

At this point all I have seen from your first list was some newbie
edits with some newbie mistakes and some stuff that looked totally
fine when using the correct imagery.

and before you started reverting all of the andrew users work, I saw
decent mapping and bad tagging from a new mapper. clearly not
vandalism.

Granted I am not the best at reviewing things by changeset so I might
have missed something, that is totally possible.

At this point I am going to stop looking into it since you have
decided to take matters into your own hands with your own solutions.

Regards,

Blake


On Sun, Oct 29, 2017 at 9:15 PM, Safwat Halaby  wrote:
>
> Due to a mailing client config error, I'm unsure if I sent my
> messages privately or to the list (or at all). At the risk of repeating
> myself:
>
> The problems are not related to Imagery at all. They're blatantly
> obvious mapping issues like:
> - removing things and re-adding them for no apparent reason
> - Adding buildings on top of pre-existing buildings
> - Adding closed ways with area=yes instead of building=yes, or with no
> tags at all
> - Intentional vandalism in some cases.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



-- 

Blake Girardot
OSM Wiki - https://wiki.openstreetmap.org/wiki/User:Bgirardot
HOTOSM Member - https://hotosm.org/users/blake_girardot
skype: jblakegirardot
Live OSM Mapper-Support channel - https://hotosm-slack.herokuapp.com/

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

Re: [OSM-talk-fr] passage du code FANTOIR de 11 à 10 chiffres

[marc marc]

Tu n'as pas vu le problème du 4 en 3ieme position dans les ref fantoir 
7540093510R et 7541093510F, ce n'est pas le code direction.

en partant de
https://www.data.gouv.fr/fr/datasets/fichier-fantoir-des-voies-et-lieux-dits/ 

cela ne change rien, cela renseigne heureusement les mêmes codes fantoir

Mais on a trouvé la réponse dans le pdf officiel qui dit "le code 
direction est égal à 0, à l'exception de quatre départements:Paris (754 
à 758), les Bouches-du-Rhône (131, 132), le Nord (591, 592) et les 
Hauts-de-Seine (921, 922). »
ils utilisent des codes départements "tordu"

donc dans le détail
7540093510R et 7541093510F sont divisée en
754 pseudo-département
0 ou 1 code direction (qu'on vire pour osm)
09 arrondissement
3510 rivoli
R ou F code contrôle

donc pour passer de fantoir 11 chiffres à osm 10 chiffres :
on vire les 6 premiers (département direction commune) qu'on remplace
par le code insee de la commune 75109
rivoli 3510

il me reste une question : pq le code contrôle F et pas R ?
au hasard selon le premier contributeur ou il y a une règle ?
car la ref osm a 10 chiffres n'est donc pas unique, elle n'est
unique que sur 9 chiffres sans code contrôle.

je pense que la page wiki ref:FR:FANTOIR aurait besoin d'être améliorée
parce qu'en l'état, en lisant le wiki on n'arrive pas au même résultat.

Le 29. 10. 17 à 21:31, Christian Quest a écrit :
> Le code direction n'apporte rien et est lié à l'organisation interne de 
> la DGFiP qui peut évoluer... alors que le reste relativement stable.
> 
> En fait notre ref:FR:FANTOIR correspond à la concaténation du code INSEE 
> de la commune (ou de l'arrondissement municipal) et du code RIVOLI de la 
> voie et de la lettre de contrôle.
> 
> Par la longueur et la lettre finale on sait si on a un code avec 
> direction ou pas, avec clé de contrôle (lettre à la fin) ou pas (chiffre 
> à la fin), donc dans tout les cas on peut s'en sortir et on a le fichier 
> complet de la DGFiP pour vérifier, surtout que celui-ci ne supprime 
> aucune info, mais la marque comme obsolète si besoin (avec date).
> 
> La source officielle pour FANTOIR c'est uniquement la DGFiP, pas la DGCL 
> (aucun idée d'où sort son fichier ni de quand il date). Le fichier 
> original est national, dispo sur: 
> https://www.data.gouv.fr/fr/datasets/fichier-fantoir-des-voies-et-lieux-dits/ 
> et mis à jour chaque trimestre.
> 
> 
> Pourquoi le 751093510F et pas le 750093510R ?
> 
> Paris est découpé en arrondissements, comme Lyon et Marseille et l'INSEE 
> attribue des codes aux arrondissements, comme pour les communes.
> 
> Par cohérence avec les codes INSEE donc, le 9ème arrondissements de 
> Paris est le 75109, le 75009 n'est pas un code INSEE et je ne comprends 
> même pas pourquoi la DGFiP a créé ces doublons.
> 
> ref:FR:FANTOIR est arrivé (de mémoire) avec l'import des adresses de 
> Nantes... et on n'avait pas les codes direction dans les données 
> opendata de la ville, ni le fichier FANTOIR complet que la DGFiP le 
> vendait à l'époque !
> 
> Le choix fait à l'époque est encore très cohérent aujourd'hui et je ne 
> vois pas de bonne raison de changer.
> 
> 
> Le 29 octobre 2017 à 21:02, marc marc  > a écrit :
> 
> Le 29. 10. 17 à 20:26, Marc M. a écrit :
> > Bonsoir,
> >
> > une discussion wikidata cherche des explications sur la ref fantoir
> > utilisée dans osm et particulièrement sur le fameux chiffre "direction"
> > qu'on n'encode pas dans osm
> > https://www.wikidata.org/wiki/Property_talk:P3182
> 
> >
> > Ce qui m'amène à la question suivante
> > exemple : http://www.openstreetmap.org/way/34681880
> 
> > Rue du Faubourg Montmartre
> >
> >> 
> https://www.collectivites-locales.gouv.fr/mise-a-disposition-gratuite-fichier-des-voies-et-des-lieux-dits-fantoir
> 
> 
> >>
> > dans le fichier idt/750, on a les 2 ref :
> > 7540093510R
> > 7541093510F
> > on vire le chiffre direction :
> > 754093510R
> > 754093510F
> > il y a une règle pour avoir choisit 751093510F dans osm au lieu de R ?
> > lettre la plus basse ? lettre lié au code direction 1 ? au hasard ?
> > Que contrôle la lettre du code de contrôle ? modulo 23 du reste de la
> > clef ou c'est attribué au hasard ?
> >
> > Cordialement,
> > Marc
> 
> et en passant, je comprend pas non plus le découpage du code 7540093510R
> en lisant https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
> 
> on est supposé avoir pour 7540093510R et 7541093510F
> ref INSEE du département sur 2 chiffres 75 ok
> code direction sur un chiffre : un 4 dans les 2 cas ?
> code INSEE de la 

Re: [Talk-at] GUSTmobil Haltepunkte (Graz Umgebung Sammel-Taxi)

[Gerald Grabner]

Das wäre natürlich super!

Mit OGD habe ich mich nicht beschäftigt, d.h. hinsichtlich Datenvorgabe kann ich nur sagen, dass die Daten möglichst einfach übertragbar und aktualisierbar sein sollten. Vielleicht hat jemand konkretere Ideen?

 

LG

Gerald

 

Gesendet: Sonntag, 29. Oktober 2017 um 13:50 Uhr
Von: "Arnold Pichler" 
An: "OpenStreetMap AT" , talk-at@openstreetmap.org
Betreff: Re: [Talk-at] GUSTmobil Haltepunkte (Graz Umgebung Sammel-Taxi)

Bin Entwickler bei GUSTmobil (eigenlich ISTmobil) und wir können die
Daten aller Punkte verfügbar machen, eigentlich eine gute Idee, diese
z.B. als ODG Schnittstelle "abgreifbar" zu machen, denn es kommen ja
laufend welche dazu, ganz selten welche weg.

Muss das mit dem Geschäftführer klären, sollte aber in unserem Sinn
sein. Gibt es irgend eine Datenvorgabe?

LG, Arnold Pichler

-- Originalnachricht --
Von: "Gerald Grabner" 
An: talk-at@openstreetmap.org
Cc:
Gesendet: 29.10.2017 13:19:35
Betreff: [Talk-at] GUSTmobil Haltepunkte (Graz Umgebung Sammel-Taxi)

>Hallo allseits,
>
>eine Frage zu den Haltepunkten von GUSTmobil
>[http://www.istmobil.at/inhalt/privatkunden/gustmobil.html]: Sollen
>diese gemappt werden, wenn ja wie? Gibt es vielleicht schon eine
>Relation welche diese sammelt?
>
>GUSTmobil basiert ja selber auf der OSM, d.h. die Haltepunkte gibt es
>wohl schon, aber vermutlich nicht öffentlich.
>
>Danke & LG
>Gerald
>
>___
>Talk-at mailing list
>Talk-at@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-at


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




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

Re: [OSM-talk-fr] passage du code FANTOIR de 11 à 10 chiffres

[Christian Quest]

Le code direction n'apporte rien et est lié à l'organisation interne de la
DGFiP qui peut évoluer... alors que le reste relativement stable.

En fait notre ref:FR:FANTOIR correspond à la concaténation du code INSEE de
la commune (ou de l'arrondissement municipal) et du code RIVOLI de la voie
et de la lettre de contrôle.

Par la longueur et la lettre finale on sait si on a un code avec direction
ou pas, avec clé de contrôle (lettre à la fin) ou pas (chiffre à la fin),
donc dans tout les cas on peut s'en sortir et on a le fichier complet de la
DGFiP pour vérifier, surtout que celui-ci ne supprime aucune info, mais la
marque comme obsolète si besoin (avec date).

La source officielle pour FANTOIR c'est uniquement la DGFiP, pas la DGCL
(aucun idée d'où sort son fichier ni de quand il date). Le fichier original
est national, dispo sur:
https://www.data.gouv.fr/fr/datasets/fichier-fantoir-des-voies-et-lieux-dits/
et mis à jour chaque trimestre.


Pourquoi le 751093510F et pas le 750093510R ?

Paris est découpé en arrondissements, comme Lyon et Marseille et l'INSEE
attribue des codes aux arrondissements, comme pour les communes.

Par cohérence avec les codes INSEE donc, le 9ème arrondissements de Paris
est le 75109, le 75009 n'est pas un code INSEE et je ne comprends même pas
pourquoi la DGFiP a créé ces doublons.

ref:FR:FANTOIR est arrivé (de mémoire) avec l'import des adresses de
Nantes... et on n'avait pas les codes direction dans les données opendata
de la ville, ni le fichier FANTOIR complet que la DGFiP le vendait à
l'époque !

Le choix fait à l'époque est encore très cohérent aujourd'hui et je ne vois
pas de bonne raison de changer.


Le 29 octobre 2017 à 21:02, marc marc  a écrit :

> Le 29. 10. 17 à 20:26, Marc M. a écrit :
> > Bonsoir,
> >
> > une discussion wikidata cherche des explications sur la ref fantoir
> > utilisée dans osm et particulièrement sur le fameux chiffre "direction"
> > qu'on n'encode pas dans osm
> > https://www.wikidata.org/wiki/Property_talk:P3182
> >
> > Ce qui m'amène à la question suivante
> > exemple : http://www.openstreetmap.org/way/34681880
> > Rue du Faubourg Montmartre
> >
> >> https://www.collectivites-locales.gouv.fr/mise-a-
> disposition-gratuite-fichier-des-voies-et-des-lieux-dits-fantoir
> >>
> > dans le fichier idt/750, on a les 2 ref :
> > 7540093510R
> > 7541093510F
> > on vire le chiffre direction :
> > 754093510R
> > 754093510F
> > il y a une règle pour avoir choisit 751093510F dans osm au lieu de R ?
> > lettre la plus basse ? lettre lié au code direction 1 ? au hasard ?
> > Que contrôle la lettre du code de contrôle ? modulo 23 du reste de la
> > clef ou c'est attribué au hasard ?
> >
> > Cordialement,
> > Marc
>
> et en passant, je comprend pas non plus le découpage du code 7540093510R
> en lisant https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
> on est supposé avoir pour 7540093510R et 7541093510F
> ref INSEE du département sur 2 chiffres 75 ok
> code direction sur un chiffre : un 4 dans les 2 cas ?
> code INSEE de la commune sur 3 chiffres mais paris est 75056
> je suppose donc qu'il faut comprendre "ou département" 75109 qui devient
> 109 si on supprime le département. mais pq l'autre a 009 ?
> code RIVOLI 2510 ok
> code contrôle R ou F ok
>
> j'ai l'impression qu'il y a un détail incorrect qlq part...
> ___
> 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] weeklyOSM - Mapbox updates

[Safwat Halaby]

On Sun, 2017-10-29 at 18:22 +, Andy Townsend wrote:
> On 29/10/2017 18:09, Safwat Halaby wrote:
> > Hmm, around the same times the Mapbox updates
> > stopped[1],  OsmCHA[2]
> > stopped showing new changesets and I reported[3] that. Perhaps it
> > was
> > an unintended side-effect of whatever Mapbox did?
> 
> That's something at your end: I think https://osmcha.mapbox.com/
> shows 
> updates from "2 minutes ago" for me.  The filters (e.g. for searching
> by 
> HOT task number) have also been working.
> 
> Best Regards,
> 
> Andy
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

There were a couple of days of no updates, but that issue has since
been acknowledged and fixed. It is all good in the present time. 

See:

https://lists.openstreetmap.org/pipermail/talk/2017-October/079053.html

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

Re: [OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[Safwat Halaby]

Due to a mailing client config error, I'm unsure if I sent my
messages privately or to the list (or at all). At the risk of repeating
myself:

The problems are not related to Imagery at all. They're blatantly
obvious mapping issues like: 
- removing things and re-adding them for no apparent reason
- Adding buildings on top of pre-existing buildings
- Adding closed ways with area=yes instead of building=yes, or with no
tags at all
- Intentional vandalism in some cases. 

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

Re: [OSM-talk-fr] passage du code FANTOIR de 11 à 10 chiffres

[marc marc]

Le 29. 10. 17 à 20:26, Marc M. a écrit :
> Bonsoir,
> 
> une discussion wikidata cherche des explications sur la ref fantoir 
> utilisée dans osm et particulièrement sur le fameux chiffre "direction" 
> qu'on n'encode pas dans osm
> https://www.wikidata.org/wiki/Property_talk:P3182
> 
> Ce qui m'amène à la question suivante
> exemple : http://www.openstreetmap.org/way/34681880
> Rue du Faubourg Montmartre
> 
>> https://www.collectivites-locales.gouv.fr/mise-a-disposition-gratuite-fichier-des-voies-et-des-lieux-dits-fantoir
>>  
>>
> dans le fichier idt/750, on a les 2 ref :
> 7540093510R
> 7541093510F
> on vire le chiffre direction :
> 754093510R
> 754093510F
> il y a une règle pour avoir choisit 751093510F dans osm au lieu de R ?
> lettre la plus basse ? lettre lié au code direction 1 ? au hasard ?
> Que contrôle la lettre du code de contrôle ? modulo 23 du reste de la 
> clef ou c'est attribué au hasard ?
> 
> Cordialement,
> Marc

et en passant, je comprend pas non plus le découpage du code 7540093510R
en lisant https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
on est supposé avoir pour 7540093510R et 7541093510F
ref INSEE du département sur 2 chiffres 75 ok
code direction sur un chiffre : un 4 dans les 2 cas ?
code INSEE de la commune sur 3 chiffres mais paris est 75056
je suppose donc qu'il faut comprendre "ou département" 75109 qui devient 
109 si on supprime le département. mais pq l'autre a 009 ?
code RIVOLI 2510 ok
code contrôle R ou F ok

j'ai l'impression qu'il y a un détail incorrect qlq part...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[Nicolás Alvarez]

2017-10-29 16:13 GMT-03:00 Blake Girardot HOT/OSM :
> Greetings,
>
> I SomeoneElse mentioned this in our HOT IRC channel.
>
> I have already asked the project creator to take a look.
>
> But, are you sure they are bad edits? did you use the 2016 imagery
> specified in the mapping projet?
>
> For example, change set 53330616, the first one i randomly looked at
> from you list looks like bad editing until you use the 2016 imagery,
> please see the linked to two images below, one with Bing/DG Premium (they
> look the same) and one with the imagery supplied with the project.
>
> So, please let us not rush to revert if you are not using the
> proper imagery.
>
> As I said, I will or someone else from HOT will look into it further,
> thank you very much for bringing it to our attention, as well as the
> other issues you pointed out, which I have not had a chance to look at
> yet.
>
> https://screenpresso.com/=l5lhb (old bing)
>
> https://screenpresso.com/=TPYpg (new aerial)

Hmm those seem to be the same image. Did you upload the wrong screenshot maybe?

-- 
Nicolás

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

[OSM-talk-fr] passage du code FANTOIR de 11 à 10 chiffres

[marc marc]

Bonsoir,

une discussion wikidata cherche des explications sur la ref fantoir 
utilisée dans osm et particulièrement sur le fameux chiffre "direction" 
qu'on n'encode pas dans osm
https://www.wikidata.org/wiki/Property_talk:P3182

Ce qui m'amène à la question suivante
exemple : http://www.openstreetmap.org/way/34681880
Rue du Faubourg Montmartre

> https://www.collectivites-locales.gouv.fr/mise-a-disposition-gratuite-fichier-des-voies-et-des-lieux-dits-fantoir
dans le fichier idt/750, on a les 2 ref :
7540093510R
7541093510F
on vire le chiffre direction :
754093510R
754093510F
il y a une règle pour avoir choisit 751093510F dans osm au lieu de R ?
lettre la plus basse ? lettre lié au code direction 1 ? au hasard ?
Que contrôle la lettre du code de contrôle ? modulo 23 du reste de la 
clef ou c'est attribué au hasard ?

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

Re: [Talk-it] formato gtfs, trasporto extraurbano Trentino, da sito dati.trentino.it.

[liste DOT girarsi AT posteo DOT eu]

Il 29/10/2017 20:05, Maurizio Napolitano ha scritto:

Il formato GTFS Ú un formato di Google per importare i dati in Google Transit.
Le specifiche sono pubbliche[2] e rilasciate in cc-by.
Esistono anche diversi tool oltre a quello di validazione offerto da google [3]
Nella pagina wiki di OSM [4] trovi molte indicazioni in merito al suo riuso.
Il tool Go-Sync[5] permette di sincronizzare i dati fra osm ed un gtfs

Purtroppo il gtfs di trentino esercizio, per l'extraurbano, Ú
distribuito senza  percorsi (shapes.txt).

[1] http://transit.google.com
[2] https://developers.google.com/transit/gtfs/reference/?csw=1
[3] https://github.com/google/transitfeed/wiki/FeedValidator
[4] https://wiki.openstreetmap.org/wiki/General_Transit_Feed_Specification
[5] https://github.com/CUTR-at-USF/gtfs-osm-sync



Sì, l'avevo visto, però a me interessano le fermate intermediarie, non 
il routing per creare relazioni dei trasporti, troppo complesso visti i 
continui cambi di orario/deviazioni dei trasporti, specie  in zona, ma 
immagino un pò in tutte le vallate, anche da punto di vista delle tratte.


Grazie per la delucidazione, comunque per quanto mi serve la tua 
risposta è più che sufficiente.


Quindi nel changeset basta "dati.trentino.it" come source?

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

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

Re: [OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[Blake Girardot HOT/OSM]

Greetings,

I SomeoneElse mentioned this in our HOT IRC channel.

I have already asked the project creator to take a look.

But, are you sure they are bad edits? did you use the 2016 imagery
specified in the mapping projet?

For example, change set 53330616, the first one i randomly looked at
from you list looks like bad editing until you use the 2016 imagery,
please see the linked to two images below, one with Bing/DG Premium (they
look the same) and one with the imagery supplied with the project.

So, please let us not rush to revert if you are not using the
proper imagery.

As I said, I will or someone else from HOT will look into it further,
thank you very much for bringing it to our attention, as well as the
other issues you pointed out, which I have not had a chance to look at
yet.

https://screenpresso.com/=l5lhb (old bing)

https://screenpresso.com/=TPYpg (new aerial)

Regards,
Blake

On Sun, Oct 29, 2017 at 6:18 PM, Safwat Halaby  wrote:
> There's a sudden influx of bad edits by different users related to
> Palestine HotOSM tasks. I don't know why. Perhaps it's a poorly-trained
> group?
>
> Incomplete list of relevant hotOSM tasks: 3441, 3447, 3759, 3768
>
> Incomplete List of bad changesets:
>
> https://www.openstreetmap.org/changeset/53330583 (reverted)
> https://www.openstreetmap.org/changeset/53330562
> https://www.openstreetmap.org/changeset/53330596
> https://osmcha.mapbox.com/changesets/53330616
> https://osmcha.mapbox.com/changesets/53330636
> https://www.openstreetmap.org/changeset/53330694
> https://www.openstreetmap.org/changeset/53330695
> https://www.openstreetmap.org/changeset/53330707 (intersecting ways)
> https://www.openstreetmap.org/changeset/53330589
> https://www.openstreetmap.org/changeset/53330728
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



-- 

Blake Girardot
Humanitarian OpenStreetMap Team

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

Re: [Talk-it] formato gtfs, trasporto extraurbano Trentino, da sito dati.trentino.it.

[Maurizio Napolitano]

Il formato GTFS è un formato di Google per importare i dati in Google Transit.
Le specifiche sono pubbliche[2] e rilasciate in cc-by.
Esistono anche diversi tool oltre a quello di validazione offerto da google [3]
Nella pagina wiki di OSM [4] trovi molte indicazioni in merito al suo riuso.
Il tool Go-Sync[5] permette di sincronizzare i dati fra osm ed un gtfs

Purtroppo il gtfs di trentino esercizio, per l'extraurbano, è
distribuito senza  percorsi (shapes.txt).

[1] http://transit.google.com
[2] https://developers.google.com/transit/gtfs/reference/?csw=1
[3] https://github.com/google/transitfeed/wiki/FeedValidator
[4] https://wiki.openstreetmap.org/wiki/General_Transit_Feed_Specification
[5] https://github.com/CUTR-at-USF/gtfs-osm-sync

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

[Talk-it] formato gtfs, trasporto extraurbano Trentino, da sito dati.trentino.it.

[liste DOT girarsi AT posteo DOT eu]

Nel sito opendata dati.trentino.it c'è un file sulle fermate autobus e 
altro che mi interessa per usare le informazioni ivi contenute[0] ad uso 
della mia zona (no import, solo sfondo e mappatura a mano), 
teoricamente/forse è in CC-BY 4.0, il dataset  parte da questa pagina 
con più file[1],però guardando l'origine sembra un estratto google[2] 
(vedi "Data e risorse"), in licenza CC-BY 2.5, che dite si può usare per 
i soli contenuti?


Ho già provato a vedere con Qgis, la posizione dei singoli punti lascia 
a desiderare (tra i 10 Mt e più, tenuto conto del lato destro e sinistro 
della strada che in alcuni casi ha solo una fermata, mentre in alcuni 
casi una per lato/direzione), le fermate però mi interessano per 
aggiungere quelle mancanti nella mia zona, in quanto vado un pò a 
memoria ed un pò a tempo perso sul posto, compreso altri mappatori al 
posto mio a tempo da destinarsi.




[0] 
http://dati.trentino.it/dataset/trasporti-pubblici-del-trentino-formato-gtfs/resource/0b1db5d6-8d2b-4f06-97f2-f65d605dfeda


[1] 
http://dati.trentino.it/dataset/trasporti-pubblici-del-trentino-formato-gtfs


[2] http://www.ttesercizio.it/TTEOpenData/

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

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

Re: [OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[Andy Townsend]

On 29/10/2017 17:18, Safwat Halaby wrote:

There's a sudden influx of bad edits by different users related to
Palestine HotOSM tasks.


There's a "I've seen a problem; what should I do?" section on 
http://wiki.osmfoundation.org/wiki/Data_Working_Group which explains the 
steps to follow.  You've already been doing that (for which thanks), but 
I mention it for the benefit of anyone else reading this who's 
unfamiliar with the process.


Where these are new mappers I'd suggest a "hello and welcome" message 
that asks a bit more about how they're contributing and what the 
problems are with it (for example - 
https://www.openstreetmap.org/way/536519974 has no tags but appears to 
be tracing over https://www.openstreetmap.org/way/519139010 from 2 
months ago).  I'm sure that these new mappers mean well, but they 
clearly haven't understood the task that they've been asked to perform 
(or perhaps that task was somewhat inappropriate for brand-new users in 
a place as densely populated as the West Bank). Try and find out if 
they're volunteers (e.g. they're volunteered to give up their own time 
to help improve the mapping in this area) or if they've perhaps been 
told to "map 100 buildings as part of this HOT task" in order to gain a 
credit for part of a course they're doing.


I'd also (and this would greatly help both the new mapper and the DWG) 
point out specific issues in each changeset, such as "way xyz does not 
have any tags, and without any tags no-one trying to use OSM data will 
know what it is" or "building abc overlaps with another building, which 
clearly can't be the case in reality".


Often there are a mix of edits from well-meaning brand-new HOT mappers - 
some that need reverting immediately because they actually break stuff 
(e.g. inadvertant node drags), some that need tidying and some that are 
perfectly OK to leave.  Having changeset discussion comments explaining 
what is what makes any future post-newbie tidy-up much easier.


Best Regards,

Andy (DWG member)


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

Re: [Talk-it] ruota idraulica di una segheria

[liste DOT girarsi AT posteo DOT eu]

Il 29/10/2017 18:14, demon.box ha scritto:

Ciao, c'era una volta una segheria alimentata ovviamente da una ruota
idraulica.
Oggi l'edificio Ú stato riconvertito in abitazione ma la ruota anche se un
po' malandata fa ancora bella mostra di sÚ: come la mappo?
Grazie
--enrico


Stando alla precedente discussione avviata da te [0], se intendi solo la 
ruota non so, mentre per il precedente uso direi:


building=yes
old:man_made=sawmill

oppure

old:craft=sawmill

in più

historic=yes



[0] http://gis.19327.n8.nabble.com/Falegnameria-Segheria-td5904631.html


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

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

Re: [OSM-talk] weeklyOSM - Mapbox updates

[Andy Townsend]

On 29/10/2017 18:09, Safwat Halaby wrote:

Hmm, around the same times the Mapbox updates stopped[1],  OsmCHA[2]
stopped showing new changesets and I reported[3] that. Perhaps it was
an unintended side-effect of whatever Mapbox did?


That's something at your end: I think https://osmcha.mapbox.com/ shows 
updates from "2 minutes ago" for me.  The filters (e.g. for searching by 
HOT task number) have also been working.


Best Regards,

Andy


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

Re: [Talk-es] Ediciones realizadas como función de un puesto de trabajo

[Xuacu]

Hola.

No se lo que opinará el resto de la comunidad, pero para mi sería
suficiente añadir un comentario estándar para las ediciones hechas
dentro del proyecto en el conjunto de cambios. De esa forma sería
fácil localizar las ediciones en caso de que hubiera algún problema.

Por ejemplo, algo como: Edificios blablabla... ## Proyecto remunerado
Loquesea ##

Un saludo.
Xuacu Saturio
Usuariu de Linux // Linux user #134680
https://www.linuxcounter.net/


El día 29 de octubre de 2017, 17:17, Iván Hernández Cazorla
 escribió:
> Gracias por tu respuesta, Esther.
>
> He estado liado para responder al correo, hasta ahora. Pero gracias a ello
> me he topado con los resultados de la encuesta [1] que has mencionado
> mientras leía el «semanarioOSM 379» [2]. Es bastante interesante en general,
> y comenta muchos de los aspectos que ambos hemos comentado. Hay algunos
> aspectos/preguntas que se han votado que me parecen muy relevantes ―cómo los
> de transparencia, la calidad de las contribuciones y la comunicación―.
>
> Creo que, tras haber reflexionado sobre lo que pregunté, lo que me has
> comentado y los resultados que he podido revisar de algunas preguntas, salvo
> alguna otra intervención que me haga cambiar de parecer, mi 'modus operandi'
> será:
>
>  * Editar con mi cuenta personal, declarando que con ella realizo ediciones
> personales y remuneradas. Detallaré que, salvo excepciones, las ediciones
> remuneradas se acotarán a un espacio de tiempo concreto ―mi horario
> laboral―.
>  * También apuntaré las vías de contacto posible que tienen conmigo, tanto
> para mis ediciones personales, como para las profesionales.
>  * Las ediciones que realice remuneradamente tendrán una etiqueta/hashtag
> que lo indique ―por ej. #nombreproyecto―.
>  * Realizaré un «feedback», posiblemente semanal, en el que indique todo
> aquello que se ha trabajado a partir del proyecto, además de los problemas
> que hayan surgido o posibles dudas. La encuesta que se realizó plantea que
> una buena parte de los votantes está de acuerdo con que las cuentas
> remuneradas realicen ese «feedback». Sin embargo, no especifican el dónde ni
> cómo, así que de momento barajo tanto un posible diario público de trabajo
> alojado en el propio sitio web del proyecto, como una entrada semanal en mi
> diario de OSM.
>
> Estoy más decidido que antes a perfilar bien todo esto, ya que por fin he
> recibido confirmación para el proyecto. Aunque, seguramente, no empiece a
> trabajar hasta principios de 2018.
>
> Sigo atento a posibles cambios sobre este tema y buscaré más en la wiki. De
> momento solo he encontrado un borrador sobre edición organizada ―«Organized
> Editing Policy»― [3].
>
> Saludos, Iván
>
> [1]:
> https://wiki.osmfoundation.org/wiki/Data_Working_Group/Results_of_Organised_Editing_Survey_2017
> [2]: http://www.weeklyosm.eu/es/archives/9571
> [3]: https://wiki.openstreetmap.org/wiki/Organized_Editing_Policy
>
> On 26/10/17 22:30, Esther Mingot wrote:
>>
>> Buenas,
>>
>>
>> partiendo de la base que OSM está creciendo en número de usuarios y cada
>> vez habrá más ediciones comunitarias o guiadas, hace poco se estuvo haciendo
>> una encuesta sobre cómo deberían ser las directrices para este tipo de
>> ediciones. Se contemplaron tanto los casos de grupos de edición que se unen
>> para mejorar una zona concreta, tipo mapatón o cursos de formación, como los
>> casos donde una o más personas editan a cuenta de un tercero (ya sea por
>> subvención, contrato, etc). No sé cómo estará el tema, tal vez algún otro
>> miembro tenga más datos al respecto o te pueda orientar sobre dónde dirigir
>> la consulta.
>>
>>
>> Sin ser una experta en el tema, los tres puntos que expones me parecen
>> bien. Tener una cuenta para todas las ediciones, o tener una para ediciones
>> personales y otra para "profesionales", va a gusto del consumidor. Mirando a
>> futuro, si hubiera alguna duda o conflicto con una de las ediciones, la
>> comunidad se pondría en contacto contigo a través del propio conjunto de
>> cambios o a través de la cuenta de usuario que esté asociada al mismo. Que
>> las ediciones hagan referencia a un proyecto, más o menos se suele hacer,
>> aunque una vez más va a gusto del consumidor. Un ejemplo serían las
>> ediciones del HOT, donde se pide expresamente que se conserve la referencia
>> al proyecto al subir el conjunto de cambios.
>>
>>
>> En todo caso, toda edición que enriquezca el proyecto será bienvenida ;-)
>>
>>
>> Saludos!
>>
>> /*
>> */
>>
>>
>>
>> 
>> *De:* Iván Hernández Cazorla 
>> *Enviado:* martes, 24 de octubre de 2017 21:51
>> *Para:* talk-es@openstreetmap.org
>> *Asunto:* [Talk-es] Ediciones realizadas como función de un puesto de
>> trabajo
>>
>> Buenas,
>>
>> No tengo claro cómo va el asunto de las ediciones realizadas a partir de
>> una función que un trabajador tiene que ejercer en su puesto de trabajo. En
>> los 

Re: [OSM-talk] weeklyOSM - Mapbox updates

[Safwat Halaby]

Hmm, around the same times the Mapbox updates stopped[1],  OsmCHA[2]
stopped showing new changesets and I reported[3] that. Perhaps it was
an unintended side-effect of whatever Mapbox did?

Just speculating.

[1] https://help.openstreetmap.org/questions/59826
[2] https://osmcha.mapbox.com/
[3] 
https://lists.openstreetmap.org/pipermail/talk/2017-October/079036.html

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

Re: [OSM-talk-fr] Directions signalisations verticales

[François Lacombe]

Le 29 octobre 2017 à 08:43, Christian Quest  a
écrit :

>
> Ce qui serait cohérent c'est d'utiliser traffic_sign=traffic_signals sur
> un noeud séparé du way (et là direction doit être en points cardinaux), et
> avoir un highway=traffic_signals sur le way avec, si besoin,
> direction=forward/backward (voire "both", mais ce n'est semble-t-il pas
> prévu).
>

Ok avec ca, ca fonctionne

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

Re: [OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[Safwat Halaby]

Here's some intentional vandalism (among the other horrible edits).

https://www.openstreetmap.org/user/A_N_D_R_E_W

There also seems to be a pattern of people removing and readding
buildings or adding buildings on top of buildings. (Why are they doing
that? Perhaps they have an assignment of a minimum additions and it's a
way to cheaply meet some quota?)

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

[OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[Safwat Halaby]

There's a sudden influx of bad edits by different users related to
Palestine HotOSM tasks. I don't know why. Perhaps it's a poorly-trained 
group?

Incomplete list of relevant hotOSM tasks: 3441, 3447, 3759, 3768

Incomplete List of bad changesets:

https://www.openstreetmap.org/changeset/53330583 (reverted)
https://www.openstreetmap.org/changeset/53330562
https://www.openstreetmap.org/changeset/53330596
https://osmcha.mapbox.com/changesets/53330616
https://osmcha.mapbox.com/changesets/53330636
https://www.openstreetmap.org/changeset/53330694
https://www.openstreetmap.org/changeset/53330695
https://www.openstreetmap.org/changeset/53330707 (intersecting ways)
https://www.openstreetmap.org/changeset/53330589
https://www.openstreetmap.org/changeset/53330728

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

[Talk-it] ruota idraulica di una segheria

[demon.box]

Ciao, c'era una volta una segheria alimentata ovviamente da una ruota
idraulica.
Oggi l'edificio è stato riconvertito in abitazione ma la ruota anche se un
po' malandata fa ancora bella mostra di sè: come la mappo?
Grazie
--enrico




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

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

Re: [Talk-es] Áreas de protección de monumentos

[Iván Hernández Cazorla]

Gracias por ambos enlaces Javier. Me apunto el primero. Sin embargo, el 
segundo es una consulta de Overpass Turbo que al ejecutarse dice: «Este 
mapa se dejó en blanco intencionalmente. (received empty dataset)»


En su momento realicé una consulta en Overpass Turbo [1] que me daba 
todos los BICs de Canarias, funcionaba sin problemas.


Saludos, Iván

[1]: http://overpass-turbo.eu/s/sFx

On 25/10/17 09:11, Javier Sánchez Portero wrote:

Te puede interesar además

https://wiki.openstreetmap.org/wiki/ES:Bienes_de_Inter%C3%A9s_Cultural_en_Canarias
http://overpass-turbo.eu/s/sAn

El 24 de octubre de 2017, 20:10, Iván Hernández Cazorla 
> escribió:


Gracias por ambos ejemplos Javier, bastante útiles para tener claro
lo que comentas ―y ambos de Canarias, por lo que me manejo mejor al
conocerlos―. Entiendo que la idea, tal y como leí en una página de
la wiki, es no complicar las relaciones más de lo que ya son. Ni
tampoco añadirles elementos que no tienen la necesidad de estar
dentro de esta.

Me apunto las etiquetas protection_title y protection_title:category
a mi lista de necesarias. La de ref:bic ya la tenía en cuenta.

Una vez más, Javier, gracias por tu explicación. La tendré en cuenta
y, en cuanto tenga un hueco, realizaré un esquema con todo ello para
que no se me olvide nada.

Saludos, Iván


On 24/10/17 08:53, Javier Sánchez Portero wrote:

Sería de esa forma pero no es imprescindible que lo hagas con una
relación. Si es un área relativamente pequeña puedes hacerlo
simplemente con una vía cerrada. Si es un área más compleja y/o
quieres aprovechar vías ya existentes, puedes hacerlo con una
relación. En ese caso no te olvides de la etiqueta type=boundary y
no es necesario que pongas la etiqueta area=yes. Aquí tienes un
ejemplo usando una vía y una relación:

http://www.openstreetmap.org/way/249934990

http://www.openstreetmap.org/relation/2621556


Los miembros de la relación deben ser las líneas que conforman el
límite del área de protección con el papel outer. Los elementos
protegidos en si mismos (edificios, los pozos de nieve del caso
anterior) no es necesario que formen parte de la relación. Tanto
la frontera del área de protección como los elementos protegidos
deben llevar las etiquetas

    ref:bic=*
    protection_title=Bien de Interés Cultural
    protection_title:category=*

El 21 de octubre de 2017, 15:39, Iván Hernández Cazorla
> escribió:

¡Vaya! Que extraño... Reviso el correo electrónico todos los
días y juraría que no recibí esos correos. Algo tuvo que
ocurrir, quizás se fueron a la carpeta de spam. Aunque no
suele pasarme con los correos de las listas, ni me ha pasado
con Talk-es, a excepción de este mismo caso.

Gracias a ambos Jesús por contestar a mi duda tan rápido, a
pesar de que no haya visto las respuestas hasta ahora. Y a ti
Jesús López por notificarme que me ya me habían respondido y
por pasarme las respuestas de nuevo. La próxima vez que pase
tanto tiempo «sin respuesta» a un mensaje de la lista me paso
por el archivo y así me ahorro mensajes como el anterior.

Entiendo entonces que lo correcto sería etiquetar el área de
protección con este conjunto:

    boundary=protected_area
    protect_class=22
    area=yes

Utilizando «22» en protect_class, dado que esta hace
referencia a «protection of sites with special architecture or
historic interest, designed and created intentionally by people».

Aún no he manipulado mucho las relaciones, así que ahí va otra
pregunta.Entiendo que esas etiquetas deberían ir en una
relación que constituiría el área de protección del monumento
y dentro de esta, se mapearían los elementos de dentro y fuera
del BIC con puntos y vías. ¿Sería correcto mapearlo así?

Relación - Área de protección (AP)
>> Puntos y vías dentro del AP, pero fuera del BIC en sí
mismo.
>> Área del BIC.
>> >> Mapeado de todo lo correspondiente dentro de ese área.

Una vez más, muchas gracias a ambos.

Saludos, Iván


On 21/10/17 15:18, Jesús Lopez wrote:

Buenas de nuevo Iván. Debes tener algún problema con el
correo de la lista. Ese mismo día te contesté:

Hola Iván.

Sí, es posible. Yo para esos casos suelo usar estas dos
etiquetas:

•boundary=protected_area
•area=yes

En esta página del wiki [1] lo tienes mejor explicado todo lo
relacionado con los monumentos.

Un saludo.
Jesús

Re: [Talk-es] Ediciones realizadas como función de un puesto de trabajo

[Iván Hernández Cazorla]

Gracias por tu respuesta, Esther.

He estado liado para responder al correo, hasta ahora. Pero gracias a 
ello me he topado con los resultados de la encuesta [1] que has 
mencionado mientras leía el «semanarioOSM 379» [2]. Es bastante 
interesante en general, y comenta muchos de los aspectos que ambos hemos 
comentado. Hay algunos aspectos/preguntas que se han votado que me 
parecen muy relevantes ―cómo los de transparencia, la calidad de las 
contribuciones y la comunicación―.


Creo que, tras haber reflexionado sobre lo que pregunté, lo que me has 
comentado y los resultados que he podido revisar de algunas preguntas, 
salvo alguna otra intervención que me haga cambiar de parecer, mi 'modus 
operandi' será:


 * Editar con mi cuenta personal, declarando que con ella realizo 
ediciones personales y remuneradas. Detallaré que, salvo excepciones, 
las ediciones remuneradas se acotarán a un espacio de tiempo concreto 
―mi horario laboral―.
 * También apuntaré las vías de contacto posible que tienen conmigo, 
tanto para mis ediciones personales, como para las profesionales.
 * Las ediciones que realice remuneradamente tendrán una 
etiqueta/hashtag que lo indique ―por ej. #nombreproyecto―.
 * Realizaré un «feedback», posiblemente semanal, en el que indique 
todo aquello que se ha trabajado a partir del proyecto, además de los 
problemas que hayan surgido o posibles dudas. La encuesta que se realizó 
plantea que una buena parte de los votantes está de acuerdo con que las 
cuentas remuneradas realicen ese «feedback». Sin embargo, no especifican 
el dónde ni cómo, así que de momento barajo tanto un posible diario 
público de trabajo alojado en el propio sitio web del proyecto, como una 
entrada semanal en mi diario de OSM.


Estoy más decidido que antes a perfilar bien todo esto, ya que por fin 
he recibido confirmación para el proyecto. Aunque, seguramente, no 
empiece a trabajar hasta principios de 2018.


Sigo atento a posibles cambios sobre este tema y buscaré más en la wiki. 
De momento solo he encontrado un borrador sobre edición organizada 
―«Organized Editing Policy»― [3].


Saludos, Iván

[1]: 
https://wiki.osmfoundation.org/wiki/Data_Working_Group/Results_of_Organised_Editing_Survey_2017

[2]: http://www.weeklyosm.eu/es/archives/9571
[3]: https://wiki.openstreetmap.org/wiki/Organized_Editing_Policy

On 26/10/17 22:30, Esther Mingot wrote:

Buenas,


partiendo de la base que OSM está creciendo en número de usuarios y cada 
vez habrá más ediciones comunitarias o guiadas, hace poco se estuvo 
haciendo una encuesta sobre cómo deberían ser las directrices para este 
tipo de ediciones. Se contemplaron tanto los casos de grupos de edición 
que se unen para mejorar una zona concreta, tipo mapatón o cursos de 
formación, como los casos donde una o más personas editan a cuenta de un 
tercero (ya sea por subvención, contrato, etc). No sé cómo estará el 
tema, tal vez algún otro miembro tenga más datos al respecto o te pueda 
orientar sobre dónde dirigir la consulta.



Sin ser una experta en el tema, los tres puntos que expones me parecen 
bien. Tener una cuenta para todas las ediciones, o tener una para 
ediciones personales y otra para "profesionales", va a gusto del 
consumidor. Mirando a futuro, si hubiera alguna duda o conflicto con una 
de las ediciones, la comunidad se pondría en contacto contigo a través 
del propio conjunto de cambios o a través de la cuenta de usuario que 
esté asociada al mismo. Que las ediciones hagan referencia a un 
proyecto, más o menos se suele hacer, aunque una vez más va a gusto del 
consumidor. Un ejemplo serían las ediciones del HOT, donde se pide 
expresamente que se conserve la referencia al proyecto al subir el 
conjunto de cambios.



En todo caso, toda edición que enriquezca el proyecto será bienvenida ;-)


Saludos!

/*
*/




*De:* Iván Hernández Cazorla 
*Enviado:* martes, 24 de octubre de 2017 21:51
*Para:* talk-es@openstreetmap.org
*Asunto:* [Talk-es] Ediciones realizadas como función de un puesto de 
trabajo


Buenas,

No tengo claro cómo va el asunto de las ediciones realizadas a partir de 
una función que un trabajador tiene que ejercer en su puesto de trabajo. 
En los proyectos Wikimedia a estas cuentas se las denomina «cuentas 
remuneradas», es decir, usuarios que cobran por un trabajo. Sus 
condiciones son las mismas que las del resto, es decir, cumplir con la 
normativa; pero sobre todo se vigila mucho que esa cuenta no esté 
haciendo ediciones promocionales ―por ej. un usuario contratado por una 
empresa o político que quiere limpiar sus «trapos sucios» presentes en 
los proyectos―.


No sé si hay algo escrito sobre ello, o si alguno podría orientarme, 
pero ahí van algunas preguntas. Si tuviese que realizar esas ediciones 
como parte de mi trabajo:


  * ¿Se tendría que utilizar una cuenta solo para esas ediciones?
  * ¿Habría que declarar que esa cuenta es la de X 

Re: [Talk-de] Fehler mit Nominatim

[Walter Nordmann]

hi martin,


Am 29.10.2017 um 16:46 schrieb Scholtes, Martin:

Hallo Walter,

ich betreibe keinen Vandalismus!
Die Relation 1104029 ist m.M. nach nicht nötig, da sie ein Gebiet umfasst, 
welches nicht explizit erfasst werden muss.
Korrekt: Deiner Meinung nach. Und was in OSM erfasst werden muß, 
entscheidest nicht du - eigentlich niemand.

Zum einen gibt es weder umgangssprachlich noch administrativ den Begriff "Daun 
Kernstadt". Zum anderen befand sich das Gebiet bereits in der Relation 971034, 
welches die Stadt Daun umfasst.

Es war nicht meine Intention einen Fehler zu beheben, nur weil der Ursprung mir 
nicht in den Kram passt. Das Problem taucht ja merkwürdigerweise nur bei dieser 
Stadt auf, so meine Meinung nach.
Nö, wenn Admingrenzen erfasst werden, werden sie auch von Nominatim 
genutzt. Dass das "Problem" nirgenswo sonst vorkommt, wird dir niemand 
glauben.


Und ich sehe auch keinerlei  "Problem" darin, dass diese Daten im 
Suchergebnis angezeigt werden.


ok, konstruiert: es könnte durchaus noch eine Rettungswache in Daun 
stehen, die halt etwas woanders liegt. Dann macht die Anzeige des 
Ortsteiles durchaus Sinn.


Zudem ist die Suche in der OSM-Karte genauso nur eine Demonstration der 
Möglichkeiten. osm.org ist nicht DIE Osm-Karte und die Suche dort ist 
nicht DIE Suche. Wenn jemand Nominatim professionell (z.B. per API-Call 
aus einer Anwendung) verwendet, kann - und wird - er die Suchergebnisse  
ggf. filtern, sodaß nur die für ihn relevanten Daten angezeigt werden. 
Das kann und will die osm.org-Seite nicht liefern.

Als letztes noch: Du musst mir nicht aufzählen, wie lange ich dabei bin und wie 
viel ich getan hab. Denn das sagt nichts über einen wirklich aus. 
Diese Info ging nicht an dich, sondern an die beteiligten Mapper. Um 
klarzustellen, dass hier kein Newbie zugeschlagen hat. Somit erspare ich 
das Suchen nach deinem Profil.



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

Re: [Talk-de] Fehler mit Nominatim

[Scholtes, Martin]

Hallo Walter,

ich betreibe keinen Vandalismus!
Die Relation 1104029 ist m.M. nach nicht nötig, da sie ein Gebiet umfasst, 
welches nicht explizit erfasst werden muss.
Zum einen gibt es weder umgangssprachlich noch administrativ den Begriff "Daun 
Kernstadt". Zum anderen befand sich das Gebiet bereits in der Relation 971034, 
welches die Stadt Daun umfasst.

Es war nicht meine Intention einen Fehler zu beheben, nur weil der Ursprung mir 
nicht in den Kram passt. Das Problem taucht ja merkwürdigerweise nur bei dieser 
Stadt auf, so meine Meinung nach.

Als letztes noch: Du musst mir nicht aufzählen, wie lange ich dabei bin und wie 
viel ich getan hab. Denn das sagt nichts über einen wirklich aus. 

LG Martin 

-Ursprüngliche Nachricht-
Von: Walter Nordmann [mailto:wnordm...@gmx.de] 
Gesendet: Sonntag, 29. Oktober 2017 16:26
An: Openstreetmap allgemeines in Deutsch 
Betreff: Re: [Talk-de] Fehler mit Nominatim

Hi.

Wollte das "Problemchen" gerade mal nachvollziehen, und auf die Suche nach 
"Rettungswache Daun" kommt als Ergebnis "Rettungswache Daun, 8, Auf'm Weiher, 
Daun, Landkreis Vulkaneifel, Rheinland-Pfalz, 54550, Deutschland"

https://wambachers-osm.website/images/osm/snaps_2017/rettungswache_daun.png

Leicht erstaunt hab ich mich mal umgesehen, und was muss ich feststellen?

https://wambachers-osm.website/images/osm/snaps_2017/rettungswache_daun2.png

User ma-rt-in hat einfach die "störende" Admingrenze gelöscht.

Ich habe mir erlaubt, diese wieder zurückzuholen:

https://wambachers-osm.website/images/osm/snaps_2017/rettungswache_daun3.png


Mein "lieber" Martin, sowas geht absolut nicht! Einfach Daten löschen, die 
einem nicht in den Kram passen, ist Vandalismus. Und dann anzunehmen, dass das 
niemand merkt, ist Blödsinn. Du bist seit über 4 Jahren dabei und hast 5400 CS 
hochgeladen (einer zuviel). Eigentlich solltest du die Regeln kenne.

Schäm dich

Walter

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

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

Re: [Talk-de] Fehler mit Nominatim

[Walter Nordmann]

Hi.

Wollte das "Problemchen" gerade mal nachvollziehen, und auf die Suche 
nach "Rettungswache Daun" kommt als Ergebnis "Rettungswache Daun, 8, 
Auf'm Weiher, Daun, Landkreis Vulkaneifel, Rheinland-Pfalz, 54550, 
Deutschland"


https://wambachers-osm.website/images/osm/snaps_2017/rettungswache_daun.png

Leicht erstaunt hab ich mich mal umgesehen, und was muss ich feststellen?

https://wambachers-osm.website/images/osm/snaps_2017/rettungswache_daun2.png

User ma-rt-in hat einfach die "störende" Admingrenze gelöscht.

Ich habe mir erlaubt, diese wieder zurückzuholen:

https://wambachers-osm.website/images/osm/snaps_2017/rettungswache_daun3.png


Mein "lieber" Martin, sowas geht absolut nicht! Einfach Daten 
löschen, die einem nicht in den Kram passen, ist Vandalismus. Und dann 
anzunehmen, dass das niemand merkt, ist Blödsinn. Du bist seit über 4 
Jahren dabei und hast 5400 CS hochgeladen (einer zuviel). Eigentlich 
solltest du die Regeln kenne.


Schäm dich

Walter

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

Re: [OSM-talk-fr] [HOT] Fwd: Tasking Manager : map tiles not loading at lower zooms

[Philippe Verdy]

There's an overload problem on the tile renderer and the tiles wanted are
missing in the server front caches (which are also overloaded or have
problems connecting to the renderers for several of the styles renderered).
Even some static images for the UI are not loading. It looks there's a
connectivity network problem between front caches and background image
servers.

2017-10-29 15:23 GMT+01:00 Nikhil VJ :

> Hello, cross-posting this to the mailing list as I just joined now:
>
> We're planning a mapping activity for rural roads in Pune district in
> India.
> Our project is here:
> http://tasks.openstreetmap.in/project/89
> (Still in draft mode)
>
> We are facing an issue in the Tasking Manager interface : Map tiles are
> not loading beyond country zoom level. The browser console shows errors.
>
> Screenshots of the interface and error messages:
> At 50km scale: https://i.imgur.com/1JFm74T.png
> At 20km scale: https://i.imgur.com/UhSrAiQ.png
> Console errors : https://i.imgur.com/dLch0Hy.png
>
> The task manager is not loading regular OSM tiles : here are a couple of
> error'd URLs:
> http://tile-a.openstreetmap.fr/hot/8/180/114.png
> http://tile-c.openstreetmap.fr/hot/8/179/114.png
>
> Since it appears to be a HOT-specific tile source, it's possible that
> those areas might not have been provisioned or something.
>
> Is there something we could do here? In the Edit mode there is an
> "Imagery" tab but I have not been able to get anything through that.
>
> Why we need to see the map behind our shapes/grid : We want to start with
> the shapes that have roads marked and work our way from there, so that we
> can connect to existing road network rather than making orphaned paths.
>
> --
> Cheers,
> Nikhil VJ
> +91-966-583-1250
> Pune, India
> DataMeet Pune chapter 
> Self-designed learner at Swaraj University  rg>
> Blog 
> Contribute 
>
>
> ___
> HOT mailing list
> h...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Woods vs Forests

[Tobias Knerr]

On 27.10.2017 00:49, Dave F wrote:
> The woods/forest problem is one of the worst tagging cock-ups in OSM.

Indeed. The current mess is especially disappointing because it hasn't
always been that way: The status quo is the result of an attempt to
"improve" the tagging years ago.

From my point of view, it's plainly obvious that there should be only
one main tag instead of two.

Details on whether the area is used for forestry, whether it is in a
"natural" state (whatever that means), or other such information can be
gathered in addition to that main tag. Gathering that secondary
information should not be a requirement for being able to map the
forest/wood in the first place.

> all areas of trees should
> be primarily tagged as natural=wood. As with other entities, any further
> details which gives clarity should be provided in sub-tags.

That would work nicely as far as I'm concerned.

Tobias

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

Re: [Talk-at] GUSTmobil Haltepunkte (Graz Umgebung Sammel-Taxi)

[Arnold Pichler]

Bin Entwickler bei GUSTmobil (eigenlich ISTmobil) und wir können die 
Daten aller Punkte verfügbar machen, eigentlich eine gute Idee, diese 
z.B. als ODG Schnittstelle "abgreifbar" zu machen, denn es kommen ja 
laufend welche dazu, ganz selten welche weg.


Muss das mit dem Geschäftführer klären, sollte aber in unserem Sinn 
sein. Gibt es irgend eine Datenvorgabe?


LG, Arnold Pichler

-- Originalnachricht --
Von: "Gerald Grabner" 
An: talk-at@openstreetmap.org
Cc:
Gesendet: 29.10.2017 13:19:35
Betreff: [Talk-at] GUSTmobil Haltepunkte (Graz Umgebung Sammel-Taxi)


Hallo allseits,

eine Frage zu den Haltepunkten von GUSTmobil 
[http://www.istmobil.at/inhalt/privatkunden/gustmobil.html]: Sollen 
diese gemappt werden, wenn ja wie? Gibt es vielleicht schon eine 
Relation welche diese sammelt?


GUSTmobil basiert ja selber auf der OSM, d.h. die Haltepunkte gibt es 
wohl schon, aber vermutlich nicht öffentlich.


Danke & LG
Gerald

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



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

Re: [Talk-de] Fehler mit Nominatim

[Scholtes, Martin]

Danke für deine Hilfe sarah


Von Samsung-Tablet gesendet
 Ursprüngliche Nachricht Von: Sarah Hoffmann  
Datum: 29.10.17  13:20  (GMT+01:00) An: Openstreetmap allgemeines in Deutsch 
 Betreff: Re: [Talk-de] Fehler mit Nominatim 
Hallo,

On Sun, Oct 29, 2017 at 12:20:14PM +0100, Scholtes, Martin wrote:
> hab seit einiger Zeit folgenden Fehler:
> 
> Bei der Abfrage einer Örtlichkeit nennt Nominatim mir die Stadt immer mit 
> „Kernstadt“ im Text.
> 
> Als Beispiel: Rettungswache Daun, 8, Auf'm Weiher, Daun (Kernstadt), Daun, 
> Landkreis Vulkaneifel, Rheinland-Pfalz, 54550, Deutschland

Das ist der Stadtteil, den Nominatim hierher nimmt:
http://www.openstreetmap.org/relation/1104029

Du kannst soetwas leicht selber recherchieren, indem
du auf http://nominatim.openstreetmap.org gehst, dort
nach der Örtlichkeit suchst, das gewünschte
Resultat anklickst und dann auf 'Details'.
Dann kommst du auf eine Seite mit allen Details, die
Nominatim zum Suchergebnis hat. Unter anderem finden
sich in der Addressliste Links zu allen OSM-Objekten
die für die Berechnung der Addresse herangezogen
wurden. In der Liste findest du auch "Daun (Kernstadt)".

Sarah

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

[Talk-at] GUSTmobil Haltepunkte (Graz Umgebung Sammel-Taxi)

[Gerald Grabner]

Hallo allseits,

eine Frage zu den Haltepunkten von GUSTmobil 
[http://www.istmobil.at/inhalt/privatkunden/gustmobil.html]: Sollen diese 
gemappt werden, wenn ja wie? Gibt es vielleicht schon eine Relation welche 
diese sammelt?

GUSTmobil basiert ja selber auf der OSM, d.h. die Haltepunkte gibt es wohl 
schon, aber vermutlich nicht öffentlich.

Danke & LG
Gerald

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

Re: [Talk-de] Fehler mit Nominatim

[Sarah Hoffmann]

Hallo,

On Sun, Oct 29, 2017 at 12:20:14PM +0100, Scholtes, Martin wrote:
> hab seit einiger Zeit folgenden Fehler:
> 
> Bei der Abfrage einer Örtlichkeit nennt Nominatim mir die Stadt immer mit 
> „Kernstadt“ im Text.
> 
> Als Beispiel: Rettungswache Daun, 8, Auf'm Weiher, Daun (Kernstadt), Daun, 
> Landkreis Vulkaneifel, Rheinland-Pfalz, 54550, Deutschland

Das ist der Stadtteil, den Nominatim hierher nimmt:
http://www.openstreetmap.org/relation/1104029

Du kannst soetwas leicht selber recherchieren, indem
du auf http://nominatim.openstreetmap.org gehst, dort
nach der Örtlichkeit suchst, das gewünschte
Resultat anklickst und dann auf 'Details'.
Dann kommst du auf eine Seite mit allen Details, die
Nominatim zum Suchergebnis hat. Unter anderem finden
sich in der Addressliste Links zu allen OSM-Objekten
die für die Berechnung der Addresse herangezogen
wurden. In der Liste findest du auch "Daun (Kernstadt)".

Sarah

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

[Talk-de] Fehler mit Nominatim

[Scholtes, Martin]

Hallo zusammen,

 

hab seit einiger Zeit folgenden Fehler:

Bei der Abfrage einer Örtlichkeit nennt Nominatim mir die Stadt immer mit 
„Kernstadt“ im Text.

Als Beispiel: Rettungswache Daun, 8, Auf'm Weiher, Daun (Kernstadt), Daun, 
Landkreis Vulkaneifel, Rheinland-Pfalz, 54550, Deutschland

 

Ich frage mich wie dies zu stande kommt, da es die einzige Stadt ist, wo es 
auftritt.

 

Lg Martin

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

[OSM-talk] Individual wiki pages (was Re: weeklyOSM #379 2017-10-17-2017-10-23)

[Andy Townsend]

On 29/10/2017 08:57, Dave F wrote:
Going off topic, I know, but why is this 'Derbyshire' page even in 
OSM's wiki? It's meant to have details about how to map not trying to 
compete with Wikipedia.


It's not competing with wikipedia.  It's a list of links to other 
OSM-related stuff and "what people are mapping or have mapped" there.  
For example, you won't find a link to the OSM boundary relation for 
Amber Valley in wikipedia, likewise not any of the long or short 
distance trails on the sub-pages (and good luck finding much of that 
information anywhere else).


Part of the reason for having trails listed was to complement 
https://wiki.openstreetmap.org/wiki/United_Kingdom_long_distance_paths 
for shorter local paths.  You can't find the names of these with 
Nominatim.  You can with taginfo (e.g. 
https://taginfo.openstreetmap.org/search?q=pennine+bridleway#values ) - 
but even then you have to go over overpass turbo to get the data and 
it's really not straightforward.


As more tools around OSM appear the need for pages like the Derbyshire 
one reduces, but there will still be a need for community-related stuff 
such as https://wiki.openstreetmap.org/wiki/Nottingham/Pub_Meetup .


Best Regards,

Andy


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

Re: [OSM-talk] weeklyOSM #379 2017-10-17-2017-10-23

[Dave F]

On 28/10/2017 21:11, ajt1...@gmail.com wrote:


If that's the case, then he's doing it wrong.  Let's take a simple 
example - https://wiki.openstreetmap.org/wiki/Derbyshire is supposed 
to be useful to local mappers and it should be easy to navigate to 
neighbouring counties.  Unfortunately it isn't due to the 
categorisation of English counties and the complete dogs breakfast 
that is 
https://wiki.openstreetmap.org/w/index.php?title=Category:Counties_in_England=history 
(primary editor Verdy p 
).


Going off topic, I know, but why is this 'Derbyshire' page even in OSM's 
wiki? It's meant to have details about how to map not trying to compete 
with Wikipedia.


DaveF


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Wiki problems (was: weeklyOSM #379 2017-10-17-2017-10-23)

[Daniel Koć]

Could we please use more descriptive subject for discussing wiki issues?


W dniu 29.10.2017 o 08:45, Simon Poole pisze:

Regardless of what measures I think are appropriate, it is clear that if
something doesn't change the net result will be a perma-ban which has
been pointed out to him multiple times and will not come as a surprise .


1. I have no personal issues with Verdy_p, but it's telling me a lot 
that also few people from the Polish OSM community thinks he deserves 
it. Nobody is proposing to ban anyone else, let alone permanently, so it 
means that he has serious problems dealing with people, which is bad - 
even if he was always right.


2. I have however a problem with wiki categories and pages not being 
refreshed, even using "purge" button. Do you know where this problem 
comes from?


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

Re: [Talk-it] Strada con limite a 5t, eccetto carico e scarico

[Dario Crespi]

Ottimo, grazie!
Avevo guardato la pagina, ma, nonostante fosse bello evidente, non l'avevo
letto :-)

Dario

Il giorno 29 ottobre 2017 07:46, Federico Cortese  ha
scritto:

> 2017-10-28 23:12 GMT+02:00 Dario Crespi :
> > C'è questa strada [1] dove i mezzi superiori alle 5 tonnellate non
> possono
> > passare, eccetto quelli che scaricano su quella stessa strada.
> > Come taggare? Per il momento ho messo solo maxweight=50
> >
>
> A me viene in mente questo:
>
> Motor vehicles heavier than 5 tonnes may only access this street for
> the purpose of delivering goods:
> motor_vehicle:conditional=delivery @ (weight>5)
>
> Tratto dalla wiki:
> https://wiki.openstreetmap.org/wiki/Key:access
>
> Ciao,
> Federico
>
> ___
> 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] weeklyOSM #379 2017-10-17-2017-10-23

[Simon Poole]

Blake

I don't think this discussion is about if verdy_p's edits are right or
wrong, expert or novice, large or small, helpful or destructive, but
more that he completely fails to achieve any consensus, or even just
issue a heads up a reasonable time in advance, before making large scale
changes that effect lots of other wiki editors and OSM users, and is
completely unable to accept not getting his way and that extends further
than just wiki structure.

We don't work that way editing OSM data and shouldn't be acceptable for
the wiki either.

Regardless of what measures I think are appropriate, it is clear that if
something doesn't change the net result will be a perma-ban which has
been pointed out to him multiple times and will not come as a surprise .

Simon


Am 28.10.2017 um 15:53 schrieb Blake Girardot:
> Greetings,
>
> As someone who has worked with Verdy P on a daily basis over the past
> few months, I find his wiki editing and organizing to be very good. He
> knows what he is doing. He is probably a top expert in wikimedia
> editing and organization, especially as it relates to the
> translateability of our wiki content, making it much more
> translateable. A very noble and critical goal.
>
> Please read his personal page on the wiki to understand his overall
> goal and why to achieve it he has made a lot (like thousands) of
> edits: https://wiki.openstreetmap.org/wiki/User:Verdy_p
>
> I understand we can all be difficult to work with at times, and
> sometimes some of us are hard to work with all the times.
>
> Verdy, I urge you to slow down on the wiki editing, listen to the
> advice and issues others are raising about your edits and interactions
> and let everyone catch up and understand your editing and organization
> improvements. You can be really hard to keep up with :) This is the
> same advice I put on your personal wiki talk page last year :)
>
> And I urge us to keep trying to find a way to understand verdy's wiki
> work and work with Verdy on the wiki. He seems to be making real,
> important, needed improvements that will make the wiki much better in
> the long term.
>
> My impression is that much of verdy's improvements are just difficult
> to understand for non wikimedia experts, difficult to explain because
> they are complicated. And add in the fact that English is not verdy's
> native language, the challenge of explaining highly technical
> wikimedia organization techniques is twice as difficult.
>
> I am no wiki expert so I can only look at from a user's perspective.
>
> He blasted through a bunch of HOT related wiki pages and I was mad he
> made a lot of changes I did not understand. I think I complained once
> and got blown off. Now that I better understand his underlying goal,
> translateability, and I see that his changes have not really affected
> anything from my user perspective, I am fine with his changes. I am ok
> with the fact that he does know a lot more about it than I do, and I
> trust his work to be improvements as I have seen it first hand as it
> relates to translations of wiki pages.
>
> Verdy, I really wish it was easier to understand what you were doing
> and it was easier to explain, I really hope you can slow down and
> focus on bringing everyone else who is concerned about your edits to
> an understanding of your methods and reasons as I will really be sad
> and you get banned from the wiki and in the long term OSM Wiki will be
> worse off without you contributing your expertise to it.
>
> Respectfully,
> Blake
>
>
> On Sat, Oct 28, 2017 at 2:29 PM, Ilya Zverev  wrote:
>> I agree.
>>
>> Verdy p is very hard to work with on the wiki, and his number of edits makes 
>> his work virtually unverifyable and unrevertable. I assume has has alienated 
>> a lot of wiki contributors, including few people I know.
>>
>> Ilya
>>
>> Andrew Hain wrote:
>>> It is now time to talk about banning Verdy p from the wiki permanently. His 
>>> behaviour over the past years makes him a contributor of net negative 
>>> value. It is exceptionally difficult to correct any mistake that he makes 
>>> and as a result people have cut down their contributions to the wiki or 
>>> given up completely. He likes to tell people that they have made mistakes 
>>> without trying to teach them what he thinks they did wrong and obfuscates 
>>> changes with mass reformatting. It is often unclear whether he is 
>>> addressing a problem that actually exists. He often projects his own 
>>> personality deficiencies onto other people. Even in the current case where 
>>> there is software that could be made more flexible, he only offers 
>>> handwaving rather than assistance.
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>
>




signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org

Re: [OSM-talk-fr] Directions signalisations verticales

[Christian Quest]

Belle incohérence du wiki...

Sur highway=traffic_signals il est clairement indiqué qu'on ne doit pas
mapper les feux de circulation de cette façon:

"The mapping of traffic signals is an abstraction that the particular
junction or way is regulated by traffic lights.
It is not a representation of a particular device.
Thus, because traffic signals can affect routing decisions, it is important
that they are attached to the ways to which they apply, and not placed
beside the way."

Un feu mappé comme cela ne sera sûrement pas pris en compte par les
calculateurs d'itinéraires.
Un tag spécifique serait plus adapté pour cartographier la position exacte
d'un équipement routier, tout comme on a un tag pour les panneaux bien
distinct de leur effet sur le réseau de circulation: maxspeed=50 sur le way
et traffic_sign=maxspeed si on veut mapper le panneau lui même.

Ce qui serait cohérent c'est d'utiliser traffic_sign=traffic_signals sur un
noeud séparé du way (et là direction doit être en points cardinaux), et
avoir un highway=traffic_signals sur le way avec, si besoin,
direction=forward/backward (voire "both", mais ce n'est semble-t-il pas
prévu).


2017-10-28 22:12 GMT+02:00 Romain MEHUT :

> Le 28 octobre 2017 à 15:58, Christian Quest  a
> écrit :
>
>
>> Je ne trouve pas la section du wiki qui décrit cela. Un lien ?
>>
>
> Oui là https://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction
> "This tag only applies for nodes that are part of a way. For traffic
> signal nodes placed at their real position next to the road, use direction
> =* with cardinal
> directions or angles as the value."
>
> Romain
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [Talk-it] Strada con limite a 5t, eccetto carico e scarico

[Federico Cortese]

2017-10-28 23:12 GMT+02:00 Dario Crespi :
> C'è questa strada [1] dove i mezzi superiori alle 5 tonnellate non possono
> passare, eccetto quelli che scaricano su quella stessa strada.
> Come taggare? Per il momento ho messo solo maxweight=50
>

A me viene in mente questo:

Motor vehicles heavier than 5 tonnes may only access this street for
the purpose of delivering goods:
motor_vehicle:conditional=delivery @ (weight>5)

Tratto dalla wiki:
https://wiki.openstreetmap.org/wiki/Key:access

Ciao,
Federico

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

Re: [Talk-cz] rozcestniky

[Tom Ka]

Ahoj, pokud by se to realizovalo, muzu poskytnou skript co pouzivam,
pripadne muzes stahovat jednoduse ode mne pres rsync (tim by se
mirrorovaly i nahledy, ktere michal nema).

Bye

Dne 29. října 2017 1:01 gorn  napsal(a):
> Michale,
>
> Uz jsem nabizel svuj server na hosting, nabidka samozrejme plati i na
> mirror. Napis nebo zavolej 777852582.
> J.
>
> Odesláno z BlueMail
>
> ___
> 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