[OSM-talk] "Limitations on mapping private information" - wiki page

2020-09-16 Thread Mateusz Konieczny via talk
https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_information

Do you think that this page is a good description of community consensus?

The page has 
"This page is under development (May 2020). It may not yet reflect community 
consensus."
and I would like to check whatever it matches community consensus well or 
mismatches it.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Website showing what was just edited

2020-09-16 Thread Mateusz Konieczny via talk

Thanks, I was looking for exactly this one!

Sep 15, 2020, 21:16 by www.ha...@gmail.com:

> It was called Show me the Way ( > https://osmlab.github.io/show-me-the-way/>  
> ).
>
> Greetings
>
> Michał
>
> wt., 15 wrz 2020, 21:11 użytkownik Mateusz Konieczny via talk <> 
> talk@openstreetmap.org> > napisał:
>
>> I remember website showing what
>> was just edited in OpenStreetMap.
>>
>> I was unable to find it.
>>
>> Is it still up?
>> ___
>>  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] "Limitations on mapping private information" - wiki page

2020-09-16 Thread Martin Koppenhoefer


sent from a phone

> On 16. Sep 2020, at 09:41, Mateusz Konieczny via talk 
>  wrote:
> 
> Do you think that this page is a good description of community consensus?


There are some points I would like to comment on:

- 
OpenStreetMap is not a property registry, thus do not map individual ownership 
of buildings or plots. There is no need to split residential landuse into 
individual plots. (Compare Parcel.)


Yes, we do not map individual ownership of land and buildings generally, but 
unless the owner is a person, we could and privacy regulations would not 
prevent us from doing it. It also isn’t an argument for refraining from mapping 
property divisions, because these are interesting regardless of _who_ is the 
owner


“some structure of a semi-public garden appear to be the borderline of being 
acceptable.“

IMHO exaggerated, semi-public objects can be mapped in all detail and aren’t 
borderline cases

Well, at least according to my understanding of the term semi-public


Cheers Martin 



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


Re: [OSM-talk] "Limitations on mapping private information" - wiki page

2020-09-16 Thread Frederik Ramm
Hi,

On 16.09.20 09:17, Mateusz Konieczny via talk wrote:
> Do you think that this page is a good description of community consensus?

I think it is about right. I have added a section on "other reasons not
to map" which is out of scope of the page, but I wouldn't want people to
say "X is not listed on that page so I can map it!"

Bye
Frederik

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

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


Re: [OSM-talk] "Limitations on mapping private information" - wiki page

2020-09-16 Thread Mateusz Konieczny via talk
Note that 
https://www.twobirds.com/en/in-focus/general-data-protection-regulation/gdpr-tracker/deceased-persons
seems to indicate that at least in some countries it is different

Denmark: "§ 2(5): Data Protection Act and the GDPR apply to deceased persons 
until 10 years after the time of death."


Sep 16, 2020, 10:42 by frede...@remote.org:

> Hi,
>
> I added a section explaining that the concept of privacy applies only to
> living human beings.
>
> Bye
> Frederik
>
> -- 
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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


Re: [OSM-talk] "Limitations on mapping private information" - wiki page

2020-09-16 Thread Mateusz Konieczny via talk



Sep 16, 2020, 10:59 by talk@openstreetmap.org:

>
> I would understand 'semi-public garden' to be, for example, a garden where 
> you pay an admission fee to enter, or one which is closed at night. Like 
> Martin, I would expect these to be completely acceptable to map.
>
Not a native speaker, not a lawyer. I would describe such areas as public 
(possibly privately owned).

> I think the intention is to deter people from mapping _fully private_ gardens 
> which can be viewed from public roads, is this correct?
>
I am not sure about other, but for me it is about discouraging mapping fully 
private garden in detail.

For example mapping garden area itself and trees (maybe even with their 
species), but
micromapping area where someone planted strawberries seems something that
is out of scope of OSM for privacy reasons.


> Nick
>
>
>
>
>
> From:>  Martin Koppenhoefer 
>  > Sent:>  16 September 2020 08:51
>  > To:>  Mateusz Konieczny 
>  > Cc:>  OSM Talk 
>  > Subject:>  Re: [OSM-talk] "Limitations on mapping private information" - 
> wiki page>  >  
>
>
> sent from a phone
>
>
>> On 16. Sep 2020, at 09:41, Mateusz Konieczny via talk 
>>  wrote:
>>  
>>
>> Do you think that this page is a good description of community consensus?
>>
>
>
> There are some points I would like to comment on:
>
> - 
> OpenStreetMap is not a property registry, thus > do not map individual 
> ownership>  of buildings or plots. There is no need to split residential 
> landuse into individual plots. (Compare > Parcel 
> > .)
>
>
> Yes, we do not map individual ownership of land and buildings generally, but 
> unless the owner is a person, we could and privacy regulations would not 
> prevent us from doing it. It also isn’t an argument for refraining from 
> mapping property divisions, because these are interesting regardless of _who_ 
> is the owner
>
>
> “some structure of a semi-public garden appear to be the borderline of being 
> acceptable.“
>
> IMHO exaggerated, semi-public objects can be mapped in all detail and aren’t 
> borderline cases
>
> Well, at least according to my understanding of the term semi-public
>
>
> Cheers Martin 
>
>
>
>

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


Re: [OSM-talk] "Limitations on mapping private information" - wiki page

2020-09-16 Thread Nick Whitelegg

Yes - that's absolutely fine! Just wanted to clarify it here so that the 
wording could be altered (I'm quite happy to do this myself).

Thanks,
Nick



From: Mateusz Konieczny via talk 
Sent: 16 September 2020 11:01
Cc: osm 
Subject: Re: [OSM-talk] "Limitations on mapping private information" - wiki page




Sep 16, 2020, 10:59 by talk@openstreetmap.org:

I would understand 'semi-public garden' to be, for example, a garden where you 
pay an admission fee to enter, or one which is closed at night. Like Martin, I 
would expect these to be completely acceptable to map.
Not a native speaker, not a lawyer. I would describe such areas as public 
(possibly privately owned).
I think the intention is to deter people from mapping _fully private_ gardens 
which can be viewed from public roads, is this correct?
I am not sure about other, but for me it is about discouraging mapping fully 
private garden in detail.

For example mapping garden area itself and trees (maybe even with their 
species), but
micromapping area where someone planted strawberries seems something that
is out of scope of OSM for privacy reasons.

Nick





From: Martin Koppenhoefer 
Sent: 16 September 2020 08:51
To: Mateusz Konieczny 
Cc: OSM Talk 
Subject: Re: [OSM-talk] "Limitations on mapping private information" - wiki page



sent from a phone

On 16. Sep 2020, at 09:41, Mateusz Konieczny via talk  
wrote:

Do you think that this page is a good description of community consensus?


There are some points I would like to comment on:

-

  *   OpenStreetMap is not a property registry, thus do not map individual 
ownership of buildings or plots. There is no need to split residential landuse 
into individual plots. (Compare 
Parcel.)


Yes, we do not map individual ownership of land and buildings generally, but 
unless the owner is a person, we could and privacy regulations would not 
prevent us from doing it. It also isn’t an argument for refraining from mapping 
property divisions, because these are interesting regardless of _who_ is the 
owner


“some structure of a semi-public garden appear to be the borderline of being 
acceptable.“

IMHO exaggerated, semi-public objects can be mapped in all detail and aren’t 
borderline cases

Well, at least according to my understanding of the term semi-public


Cheers Martin




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


Re: [OSM-talk] "Limitations on mapping private information" - wiki page

2020-09-16 Thread Mateusz Konieczny via talk
If you (or anyone else) see way to improve it - feel free to do this.

So far (at least in my opinion) this page benefited from edits of different 
people,
so far there was also no issues with people having incompatible opinions about
what is the consensus opinion.


Sep 16, 2020, 12:04 by nick.whitel...@solent.ac.uk:

>
> Yes - that's absolutely fine! Just wanted to clarify it here so that the 
> wording could be altered (I'm quite happy to do this myself).
>
> Thanks,
> Nick
>
>
>
>
>
> From:>  Mateusz Konieczny via talk 
>  > Sent:>  16 September 2020 11:01
>  > Cc:>  osm 
>  > Subject:>  Re: [OSM-talk] "Limitations on mapping private information" - 
> wiki page>  >  
>
>
>
> Sep 16, 2020, 10:59 by talk@openstreetmap.org:
>
>>
>> I would understand 'semi-public garden' to be, for example, a garden where 
>> you pay an admission fee to enter, or one which is closed at night. Like 
>> Martin, I would expect these to be completely acceptable to map.
>>
> Not a native speaker, not a lawyer. I would describe such areas as public 
> (possibly privately owned).
>
>> I think the intention is to deter people from mapping _fully private_ 
>> gardens which can be viewed from public roads, is this correct?
>>
> I am not sure about other, but for me it is about discouraging mapping fully 
> private garden in detail.
>
> For example mapping garden area itself and trees (maybe even with their 
> species), but
> micromapping area where someone planted strawberries seems something that
> is out of scope of OSM for privacy reasons.
>
>
>> Nick
>>
>>
>>
>>
>>
>> From:>>  Martin Koppenhoefer 
>>  >> Sent:>>  16 September 2020 08:51
>>  >> To:>>  Mateusz Konieczny 
>>  >> Cc:>>  OSM Talk 
>>  >> Subject:>>  Re: [OSM-talk] "Limitations on mapping private information" 
>> - wiki page>>  
>>
>>
>> sent from a phone
>>
>>
>>> On 16. Sep 2020, at 09:41, Mateusz Konieczny via talk 
>>>  wrote:
>>>
>>>
>>> Do you think that this page is a good description of community consensus?
>>>
>>
>>
>> There are some points I would like to comment on:
>>
>> - 
>> OpenStreetMap is not a property registry, thus >> do not map individual 
>> ownership>>  of buildings or plots. There is no need to split residential 
>> landuse into individual plots. (Compare >> Parcel 
>> >> .)
>>
>>
>> Yes, we do not map individual ownership of land and buildings generally, but 
>> unless the owner is a person, we could and privacy regulations would not 
>> prevent us from doing it. It also isn’t an argument for refraining from 
>> mapping property divisions, because these are interesting regardless of 
>> _who_ is the owner
>>
>>
>> “some structure of a semi-public garden appear to be the borderline of being 
>> acceptable.“
>>
>> IMHO exaggerated, semi-public objects can be mapped in all detail and aren’t 
>> borderline cases
>>
>> Well, at least according to my understanding of the term semi-public
>>
>>
>> Cheers Martin 
>>
>>
>>
>>
>
>

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


Re: [OSM-talk] "Limitations on mapping private information" - wiki page

2020-09-16 Thread Mateusz Konieczny via talk
"mapping the location of safe houses for victims of domestic violence"

do you think that it would be OK to change that to

"mapping the location of unsigned safe houses for victims of domestic violence"
?

I would expect that the first type would be not mappable and second would be
mappable, but I had no real contact with either type.

I added 
https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_information#Limitations
to describe limitations of that page


Sep 16, 2020, 10:24 by frede...@remote.org:

> Hi,
>
> On 16.09.20 09:17, Mateusz Konieczny via talk wrote:
>
>> Do you think that this page is a good description of community consensus?
>>
>
> I think it is about right. I have added a section on "other reasons not
> to map" which is out of scope of the page, but I wouldn't want people to
> say "X is not listed on that page so I can map it!"
>
> Bye
> Frederik
>
> -- 
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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


Re: [OSM-talk] "Limitations on mapping private information" - wiki page

2020-09-16 Thread Mateusz Konieczny via talk



Sep 16, 2020, 11:38 by o...@imagico.de:

> On Wednesday 16 September 2020, Martin Koppenhoefer wrote:
>
>>
>> > simple:  Individual humans as well as their activities and social
>> > interactions between individual humans - including permanent
>> > physical manifestations of those - are not as such part of the
>> > verifiable geography we intend to record.
>>
>> +0.9, I'd make it more precise: "private activities and private
>> social interactions"
>>
>
> No, public activities of individual humans are not as such part of the 
> verifiable geography either.  If my neighbor takes their dog for a walk 
> on a certain route every day that is a public activity - yet does not 
> belong in OSM.
>
But if they manage to create a path as result of taking the same route 
repeatedly
it becomes a mappable feature.

I feel that "permanent physical manifestations of those" includes far too many
things that are actually mappable.

What about buildings? Many of them are also "physical manifestations of those"
and not visible from public land. I would still consider them as mappable
and verifiable - we can do this using aerial images and so on.

>> > The private swimming pool and the private driveway become part of
>> > the verifiable geography because members of society on a larger
>> > scale (i.e. not just the personal social environment of the owner)
>> > interact with them on a routine basis.
>>
>> I'd question this. Noone has to show their private swimming pool or
>> driveway to anybody, clearly not on a "larger scale". (I am still for
>> mapping private swimming pools, and driveways, as long as we do not
>> associate an individual with it, it has nothing to do with privacy.)
>>
>> >   In those cases mostly visually - but that can
>> > be sufficient.
>>
>> mostly you can't see private swimming pools from the street, and
>> according to the area, you also might not be able to see the
>> driveway.
>>
>
> We might have different ideas of what a driveway is but a private 
> driveway as i imagine it is part of the verifiable geography among 
> other things because you have to take notice of cars coming out of 
> private driveways as you drive along a public road.  In other words: 
> The driveway becomes part of the verifiable geography by being used as 
> a driveway.
>
> For swimming pools that is certainly a matter of size - large swimming 
> pools are however major constructions and major users of water supplies 
> as well as reservoirs of water - to be used for example by firefighters 
> in an emergency.  That is where i would see the interaction on a larger 
> scale.
>
I would say that if someone has a private island it is still perfectly fine
to map buildings, driveways*, garden areas there - even if sole source
of map data is an aerial image.

*leading from private palace to a private dock, not connected to
any public road.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] "Limitations on mapping private information" - wiki page

2020-09-16 Thread Martin Koppenhoefer
Am Mi., 16. Sept. 2020 um 11:44 Uhr schrieb Christoph Hormann <
o...@imagico.de>:

> >
> > +0.9, I'd make it more precise: "private activities and private
> > social interactions"
>
> No, public activities of individual humans are not as such part of the
> verifiable geography either.  If my neighbor takes their dog for a walk
> on a certain route every day that is a public activity - yet does not
> belong in OSM.
>


I agree it does not belong in OSM because we do not collect information
about individual people and because we only map signposted routes. But as
you also include "permanent
physical manifestations of those" this must somehow be limited. If my
neighbour went everyday at the same spot walking her dog, crossing a lawn
and thereby creating a small path, the result is something I would want to
map. As long as I don't tell anybody that it was my neighbour walking her
dog creating the informal path, there should not be a problem.


We might have different ideas of what a driveway is but a private
> driveway as i imagine it is part of the verifiable geography among
> other things because you have to take notice of cars coming out of
> private driveways as you drive along a public road.  In other words:
> The driveway becomes part of the verifiable geography by being used as
> a driveway.
>


this is only the last part of the driveway, between the gate (if any) and
the road, typically it isn't "private" in the sense that it is on public
ground, at least in parts.



>
> For swimming pools that is certainly a matter of size - large swimming
> pools are however major constructions and major users of water supplies
> as well as reservoirs of water - to be used for example by firefighters
> in an emergency.  That is where i would see the interaction on a larger
> scale.
>


As I said, I do not question that these are useful to map (also as
consumers of large quantities of water, I know, currently you can use as
much water as you like, if you pay for it, but drinking water is a limited
resource on the planet, so also morally I find it ok to map them, besides
their usefulness in case of an emergency). But they are not public and the
public is not interacting with them "on a larger scale", this is what I
wanted to point out.

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


Re: [OSM-talk] "Limitations on mapping private information" - wiki page

2020-09-16 Thread Martin Koppenhoefer
Am Mi., 16. Sept. 2020 um 12:04 Uhr schrieb Mateusz Konieczny via talk <
talk@openstreetmap.org>:

> Sep 16, 2020, 10:59 by talk@openstreetmap.org:
>
> I would understand 'semi-public garden' to be, for example, a garden where
> you pay an admission fee to enter, or one which is closed at night. Like
> Martin, I would expect these to be completely acceptable to map.
>
> Not a native speaker, not a lawyer. I would describe such areas as public
> (possibly privately owned).
>


the term "semi public" for me applies to private property which is
accessible by a larger amount of people. It could be a shopping mall, the
green areas you may find for shared use in social housing projects (at
least those that were built in more socially aware times), also inner
courtyards which are accessible during the daytime, generally all
accessible private areas.

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


Re: [OSM-talk] "Limitations on mapping private information" - wiki page

2020-09-16 Thread Andrew Harvey
On Wed, 16 Sep 2020 at 18:04, Martin Koppenhoefer 
wrote:

> Yes, we do not map individual ownership of land and buildings generally,
> but unless the owner is a person, we could and privacy regulations would
> not prevent us from doing it. It also isn’t an argument for refraining from
> mapping property divisions, because these are interesting regardless of
> _who_ is the owner
>

Tangentially, at least where the cadastre matches what's on the ground, I
hope one day we can include the cadastre in OSM, with the address and
landuse information tagged on the parcel. Instead of trying to trace out
the outline of the parcels in a block in an editor I could just select all
the parcels and say they are residential parcels and that's the landuse
done.

Indeed I agree with Martin, that there is a lot of value in knowing about
parcels completely without any kind of ownership information attached. One
can do analysis on lot size, building floor space ratio to lot size, etc.
if we mapped the parcel.

> Limit the detail of mapping private backyards. As a guideline,
permanently installed private swimming pools, or some structure of a
semi-public garden appear to be the borderline of being acceptable. Add
access=private as appropriate.

Agreed backyard pools are widespread mapped and seem to be tolerated and
okay, backyard tennis courts I would put into the same category.

I think rooftop solar on residential houses is also mapped in places, and I
think is okay.

Given all of this is not personally identifiable and already public in
aerial imagery etc. I agree including this in OSM shouldn't pose an issue.

Under other reasons not to map, I think we could include Aboriginal sacred
sites where "The traditional owners and their representatives have asked
that the locations of other sites be kept private to protect them and
maintain their sanctity.".

But otherwise I feel the page is a good description of community consensus.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] "Limitations on mapping private information" - wiki page

2020-09-16 Thread Christoph Hormann via talk
On Wednesday 16 September 2020, Mateusz Konieczny via talk wrote:
> https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_in
>formation

I think while that page does not contain gross factual errors as far as 
i see it could be fairly misleading for people unfamiliar with OSM 
otherwise:

* it start with "The freedom to map the world..." which implies the aim 
of OSM is "to map the world" - which it is not.  OSM aims to collect 
verifiable local knowledge of the geography of the world.  That is 
something different.

* The list of things to "do not" kind of implies this is a distinct set 
of rules separate from and above the general goals and values of the 
project (i.e. verifiable local knowledge of the geography).  I don't 
think that is the case.

My own take on privacy related limitations to mapping would be much more 
simple:  Individual humans as well as their activities and social 
interactions between individual humans - including permanent physical 
manifestations of those - are not as such part of the verifiable 
geography we intend to record.

The private swimming pool and the private driveway become part of the 
verifiable geography because members of society on a larger scale (i.e. 
not just the personal social environment of the owner) interact with 
them on a routine basis.  In those cases mostly visually - but that can 
be sufficient.

I think with this clarification everything on your list of things not to 
map due to privacy concerns is covered by being not mappable due to not 
being part of the verifiable geography.

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

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


Re: [OSM-talk] "Limitations on mapping private information" - wiki page

2020-09-16 Thread Nick Whitelegg via talk

I would understand 'semi-public garden' to be, for example, a garden where you 
pay an admission fee to enter, or one which is closed at night. Like Martin, I 
would expect these to be completely acceptable to map.

I think the intention is to deter people from mapping _fully private_ gardens 
which can be viewed from public roads, is this correct?

Nick



From: Martin Koppenhoefer 
Sent: 16 September 2020 08:51
To: Mateusz Konieczny 
Cc: OSM Talk 
Subject: Re: [OSM-talk] "Limitations on mapping private information" - wiki page



sent from a phone

On 16. Sep 2020, at 09:41, Mateusz Konieczny via talk  
wrote:

Do you think that this page is a good description of community consensus?


There are some points I would like to comment on:

-

  *   OpenStreetMap is not a property registry, thus do not map individual 
ownership of buildings or plots. There is no need to split residential landuse 
into individual plots. (Compare 
Parcel.)


Yes, we do not map individual ownership of land and buildings generally, but 
unless the owner is a person, we could and privacy regulations would not 
prevent us from doing it. It also isn’t an argument for refraining from mapping 
property divisions, because these are interesting regardless of _who_ is the 
owner


“some structure of a semi-public garden appear to be the borderline of being 
acceptable.“

IMHO exaggerated, semi-public objects can be mapped in all detail and aren’t 
borderline cases

Well, at least according to my understanding of the term semi-public


Cheers Martin



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


Re: [OSM-talk] "Limitations on mapping private information" - wiki page

2020-09-16 Thread Martin Koppenhoefer
Am Mi., 16. Sept. 2020 um 10:48 Uhr schrieb Christoph Hormann via talk <
talk@openstreetmap.org>:

> * it start with "The freedom to map the world..." which implies the aim
> of OSM is "to map the world" - which it is not.  OSM aims to collect
> verifiable local knowledge of the geography of the world.  That is
> something different.
>


checking with reality, it is clear that many mappers also share the
"mapping the world" goal and are not just mapping things with which they
are acquainted.


My own take on privacy related limitations to mapping would be much more
> simple:  Individual humans as well as their activities and social
> interactions between individual humans - including permanent physical
> manifestations of those - are not as such part of the verifiable
> geography we intend to record.
>


+0.9, I'd make it more precise: "private activities and private social
interactions"



>
> The private swimming pool and the private driveway become part of the
> verifiable geography because members of society on a larger scale (i.e.
> not just the personal social environment of the owner) interact with
> them on a routine basis.



I'd question this. Noone has to show their private swimming pool or
driveway to anybody, clearly not on a "larger scale". (I am still for
mapping private swimming pools, and driveways, as long as we do not
associate an individual with it, it has nothing to do with privacy.)



>   In those cases mostly visually - but that can
> be sufficient.
>


mostly you can't see private swimming pools from the street, and according
to the area, you also might not be able to see the driveway.

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


Re: [OSM-talk] "Limitations on mapping private information" - wiki page

2020-09-16 Thread Frederik Ramm
Hi,

I added a section explaining that the concept of privacy applies only to
living human beings.

Bye
Frederik

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

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


Re: [OSM-talk] Website showing what was just edited

2020-09-16 Thread Andrew Harvey
Other tools also listed at
https://wiki.openstreetmap.org/wiki/List_of_OSM-based_services#Live.2Freal-time_edits_to_OSM_data

On Wed, 16 Sep 2020 at 05:20, Michał Brzozowski  wrote:

> It was called Show me the Way ( https://osmlab.github.io/show-me-the-way/
> ).
>
> Greetings
>
> Michał
>
> wt., 15 wrz 2020, 21:11 użytkownik Mateusz Konieczny via talk <
> talk@openstreetmap.org> napisał:
>
>> I remember website showing what
>> was just edited in OpenStreetMap.
>>
>> I was unable to find it.
>>
>> Is it still up?
>> ___
>> 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] "Limitations on mapping private information" - wiki page

2020-09-16 Thread Christoph Hormann
On Wednesday 16 September 2020, Martin Koppenhoefer wrote:
>
> > simple:  Individual humans as well as their activities and social
> > interactions between individual humans - including permanent
> > physical manifestations of those - are not as such part of the
> > verifiable geography we intend to record.
>
> +0.9, I'd make it more precise: "private activities and private
> social interactions"

No, public activities of individual humans are not as such part of the 
verifiable geography either.  If my neighbor takes their dog for a walk 
on a certain route every day that is a public activity - yet does not 
belong in OSM.

> > The private swimming pool and the private driveway become part of
> > the verifiable geography because members of society on a larger
> > scale (i.e. not just the personal social environment of the owner)
> > interact with them on a routine basis.
>
> I'd question this. Noone has to show their private swimming pool or
> driveway to anybody, clearly not on a "larger scale". (I am still for
> mapping private swimming pools, and driveways, as long as we do not
> associate an individual with it, it has nothing to do with privacy.)
>
> >   In those cases mostly visually - but that can
> > be sufficient.
>
> mostly you can't see private swimming pools from the street, and
> according to the area, you also might not be able to see the
> driveway.

We might have different ideas of what a driveway is but a private 
driveway as i imagine it is part of the verifiable geography among 
other things because you have to take notice of cars coming out of 
private driveways as you drive along a public road.  In other words:  
The driveway becomes part of the verifiable geography by being used as 
a driveway.

For swimming pools that is certainly a matter of size - large swimming 
pools are however major constructions and major users of water supplies 
as well as reservoirs of water - to be used for example by firefighters 
in an emergency.  That is where i would see the interaction on a larger 
scale.

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

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


Re: [OSM-talk] "Limitations on mapping private information" - wiki page

2020-09-16 Thread Christoph Hormann
On Wednesday 16 September 2020, Mateusz Konieczny via talk wrote:
>
> But if they manage to create a path as result of taking the same
> route repeatedly it becomes a mappable feature.
>
> I feel that "permanent physical manifestations of those" includes far
> too many things that are actually mappable.

That is why i wrote "are not *as such* part of the verifiable 
geography".

Practically an established (as opposed to constructed) path is usually 
the result of the collective activities of many individuals which does 
not fall under the criterion of activities of individual humans as 
such.

To give you another example (one without any physical manifestation):  
If the driver of a bus routinely stops at a certain place between 
regular stops to let on/off a specific individual that is not a bus 
stop to be mapped in OSM.  If however that irregular stop starts 
getting used by other people as well it becomes a mappable bus stop.

> What about buildings? Many of them are also "physical manifestations
> of those" and not visible from public land. I would still consider
> them as mappable and verifiable - we can do this using aerial images
> and so on.

Land ownership is not a meaningful criterion - otherwise huge parts of 
the map would need to stay empty.

Houses serving as private homes are subject to interaction with society 
in general on a larger scale for example:

* by serving as an orientation point for navigation
* by being the target of mail and package delivery
* by being the target of door-to-door salespeople
* by being the target of trick-or-treating
* by being a place to walk up to and ring to ask for directions if you 
are lost or for help in case of an emergency.

> I would say that if someone has a private island it is still
> perfectly fine to map buildings, driveways*, garden areas there -
> even if sole source of map data is an aerial image.
>
> *leading from private palace to a private dock, not connected to
> any public road.

Practically such places are usually subject to quite significant 
interaction with society in general - like for example staff, 
craftspeople, construction workers etc.  As a whole and in its larger 
structures like you mentioned i do not see how this would typically 
qualify as physical manifestations of activities of *individual* 
humans.  Just because an individual pays for larger scale activities 
does not necessarily make these activities those of that individual.

The private island case is limited simply by basic practical 
verifiability.  What you can see on imagery taken from outside is 
verifiable, everything else is not.  Actual privacy issue (like someone 
doing detailed indoor mapping with the help of a telescope) is probably 
less an issue here than for an individual house.

Or in other words:  Rich people cannot claim a larger scope of privacy 
just because they can own and fence in a larger area of land.

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

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


Re: [OSM-talk] "Limitations on mapping private information" - wiki page

2020-09-16 Thread Dave F via talk

The first two bullet points are poorly worded:

building=house is "where individual people live".

"There is no need to split residential landuse into individual plots."
if that means the actual tag landuse=residential, then I'd probably 
agree, but there is nothing wrong with this level of detail mapping:

https://www.openstreetmap.org/#map=18/52.51352/-1.85486

The wording , as it's written currently, contradicts the last point, 
which I believe to be correct.


The other points fall under "too transient to map".

DaveF



On 16/09/2020 08:17, Mateusz Konieczny via talk wrote:

https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_information

Do you think that this page is a good description of community consensus?

The page has
"This page is under development (May 2020). It may not yet reflect 
community consensus."
and I would like to check whatever it matches community consensus well 
or mismatches it.


___
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-it] Altra presenza ingombrante di Google Maps

2020-09-16 Thread Martin Koppenhoefer via Talk-it


sent from a phone

> On 16. Sep 2020, at 13:49, Lorenzo Rolla  wrote:
> 
> Gentilissimi, in questo sito governativo, Google maps è presente... ancora! 
> Sono proprio affezionati...
> 
> https://www.autoconsumo.gse.it/simulatore/input-base


al proposito, sapete se l’utilizzo è legale in UE? C’era quella sentenza a 
livello europeo che il privacy shield era nullo, ma non ricordo più bene, credo 
c’era un periodo di transizione (non ne sono certo).
Gli utenti Googlemaps hanno probabilmente già dato esplicito consenso di essere 
venduti, ma gli altri?


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


Re: [Talk-it] Altra presenza ingombrante di Google Maps

2020-09-16 Thread Edoardo Yossef Marascalchi
non mi pare proprio sia un sito governativo, quanto di un gestore
energetico indipendente.

On Wed, Sep 16, 2020 at 2:49 PM Lorenzo Rolla  wrote:

> Gentilissimi, in questo sito governativo, Google maps è presente...
> ancora! Sono proprio affezionati...
>
> https://www.autoconsumo.gse.it/simulatore/input-base
>
> --
> Lorenzo Rolla
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>


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


Re: [Talk-it] Altra presenza ingombrante di Google Maps

2020-09-16 Thread Fabio Bettani
È una controllata del Ministero dell'Economia (
https://it.wikipedia.org/wiki/Gestore_dei_servizi_energetici)

Situazione per certi versi analoga a Rete Ferroviaria Italiana, che pure
usa Google Maps sulle proprie pagine...*
* https://www.rfi.it/it/stazioni.html

--
Fabio


Il giorno mer 16 set 2020 alle ore 14:10 Edoardo Yossef Marascalchi <
e.marascal...@gmail.com> ha scritto:

> non mi pare proprio sia un sito governativo, quanto di un gestore
> energetico indipendente.
>
> On Wed, Sep 16, 2020 at 2:49 PM Lorenzo Rolla 
> wrote:
>
>> Gentilissimi, in questo sito governativo, Google maps è presente...
>> ancora! Sono proprio affezionati...
>>
>> https://www.autoconsumo.gse.it/simulatore/input-base
>>
>> --
>> Lorenzo Rolla
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>
>
> --
> Edoardo Yossef Marascalchi
> skype: asca_edom
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Altra presenza ingombrante di Google Maps

2020-09-16 Thread Lorenzo Rolla
Esatto, stavo per rispondere a Edoardo la stessa cosa. :)

Il giorno mer 16 set 2020 alle 14:33 Fabio Bettani 
ha scritto:

> È una controllata del Ministero dell'Economia (
> https://it.wikipedia.org/wiki/Gestore_dei_servizi_energetici)
>
> Situazione per certi versi analoga a Rete Ferroviaria Italiana, che pure
> usa Google Maps sulle proprie pagine...*
> * https://www.rfi.it/it/stazioni.html
>
> --
> Fabio
>
>
> Il giorno mer 16 set 2020 alle ore 14:10 Edoardo Yossef Marascalchi <
> e.marascal...@gmail.com> ha scritto:
>
>> non mi pare proprio sia un sito governativo, quanto di un gestore
>> energetico indipendente.
>>
>> On Wed, Sep 16, 2020 at 2:49 PM Lorenzo Rolla 
>> wrote:
>>
>>> Gentilissimi, in questo sito governativo, Google maps è presente...
>>> ancora! Sono proprio affezionati...
>>>
>>> https://www.autoconsumo.gse.it/simulatore/input-base
>>>
>>> --
>>> Lorenzo Rolla
>>>
>>>
>>>
>>> ___
>>>
>>>
>>> Talk-it mailing list
>>>
>>>
>>> Talk-it@openstreetmap.org
>>>
>>>
>>> https://lists.openstreetmap.org/listinfo/talk-it
>>>
>>>
>>>
>>
>> --
>> Edoardo Yossef Marascalchi
>> skype: asca_edom
>>
>>
>> ___
>>
>>
>> Talk-it mailing list
>>
>>
>> Talk-it@openstreetmap.org
>>
>>
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>>
>>
>
> ___
>
> Talk-it mailing list
>
> Talk-it@openstreetmap.org
>
> https://lists.openstreetmap.org/listinfo/talk-it
>
> --
Lorenzo Rolla
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


[Talk-it] Altra presenza ingombrante di Google Maps

2020-09-16 Thread Lorenzo Rolla
Gentilissimi, in questo sito governativo, Google maps è presente... ancora!
Sono proprio affezionati...

https://www.autoconsumo.gse.it/simulatore/input-base

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


Re: [OSM-talk] "Limitations on mapping private information" - wiki page

2020-09-16 Thread Martin Koppenhoefer
Am Mi., 16. Sept. 2020 um 13:30 Uhr schrieb Christoph Hormann <
o...@imagico.de>:

> Or in other words:  Rich people cannot claim a larger scope of privacy
> just because they can own and fence in a larger area of land.



you are dreaming. Maybe they cannot rightfully claim a different treatment,
but clearly they will benefit from more privacy through physical distance
(compensated by more interest in their life and property, they might end up
having less privacy).

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


Re: [Talk-GB] Overpass query strangeness within iD

2020-09-16 Thread Mateusz Konieczny via Talk-GB
1) it is not a bug of default style at all - what is displayed in tiles is not 
related
(both are using OSM data and here similarities end)
2) it is not a Mapnik bug - it is a library used by OSM Carto (default map 
style)
3) it is not in edit mode, so it is likely not an iD bug (maybe it uses an iD 
presets that have some bug)

Is it still visible in edit mode? The it may be an iD bug.

4) Which exactly language settings you have? 

(a) In OSM settings
(b) In browser
(c) In OS

For me this is not present,
I see Polish description ("Budynek przemysłowy itp group 
") as I selected
Polish as preferred language in OSM settings.

Sep 16, 2020, 08:57 by o...@live.co.uk:

>
> Hi Paul,
>
>
>  
>
>
> I’m not sure if the fault is with the ID viewer, mapnik, or overpass-api 
> really. ID bugs can be reported/tracked through its GitHub repo > 
> https://github.com/openstreetmap/iD
>
>
>  
>
>
> For others curious, an example is go to >  
> https://www.openstreetmap.org/#map=19/52.37824/-1.23676>  and right click> 
> query features on say, the ITP building or air ambulance. It will show “> 
> Индустриална сграда > itp group> ” on the results where you choose which 
> element you want more detail on.
>
>
>  
>
>
> I’m not that familiar with the codebase but it looks like there has been 
> quite a lot of activity in the localisation section, so it is possibly a 
> recently introduced bug.
>
>
>  
>
>
> Gareth
>
>
>  
>
>
>
> From: > Paul Berry 
>  > Sent: > 16 September 2020 00:21
>  > To: > Talk GB 
>  > Subject: > [Talk-GB] Overpass query strangeness within iD
>
>
>
>  
>
>
> Hi all,
>
>
>  
>
>
> Not sure who to direct this to so apologies for targeting the mailing list. 
> However, I hope the right people can be found this way.
>
>
>  
>
>
> If you use the query feature within iD (which uses the Overpass API) and 
> point at a commercial building you get a Bulgarian label in the results set 
> instead of an English one: Търговска Сграда, which translates as "commercial 
> building" - there might be other cosmetic bugs out there.
>
>
>  
>
>
> Regards,
>
>
> Paul
>
>
>  
>
>

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


Re: [Talk-GB] Overpass query strangeness within iD

2020-09-16 Thread Gareth L
Morning Mateusz,

You’re right, it’s not encountered in edit mode.

4:

  1.  “en-GB en”
  2.  “en-GB”
  3.  System Locale: en-us;English (United States)*

Input Locale:  en-gb;English (United Kingdom)

*damn, i’m normally better at keeping it en-gb!

Gareth

Sent from Mail for Windows 10

From: Mateusz Konieczny
Sent: 16 September 2020 08:09
To: Gareth L
Cc: Paul Berry; Talk 
GB
Subject: Re: [Talk-GB] Overpass query strangeness within iD

1) it is not a bug of default style at all - what is displayed in tiles is not 
related
(both are using OSM data and here similarities end)
2) it is not a Mapnik bug - it is a library used by OSM Carto (default map 
style)
3) it is not in edit mode, so it is likely not an iD bug (maybe it uses an iD
presets that have some bug)

Is it still visible in edit mode? The it may be an iD bug.

4) Which exactly language settings you have?

(a) In OSM settings
(b) In browser
(c) In OS

For me this is not present,
I see Polish description ("Budynek przemysłowy itp 
group") as I selected
Polish as preferred language in OSM settings.

Sep 16, 2020, 08:57 by o...@live.co.uk:
Hi Paul,

I’m not sure if the fault is with the ID viewer, mapnik, or overpass-api 
really. ID bugs can be reported/tracked through its GitHub repo 
https://github.com/openstreetmap/iD

For others curious, an example is go to 
https://www.openstreetmap.org/#map=19/52.37824/-1.23676 and right click> query 
features on say, the ITP building or air ambulance. It will show “Индустриална 
сграда itp group” on the results where you choose which element you want more 
detail on.

I’m not that familiar with the codebase but it looks like there has been quite 
a lot of activity in the localisation section, so it is possibly a recently 
introduced bug.

Gareth

From: Paul Berry
Sent: 16 September 2020 00:21
To: Talk GB
Subject: [Talk-GB] Overpass query strangeness within iD

Hi all,

Not sure who to direct this to so apologies for targeting the mailing list. 
However, I hope the right people can be found this way.

If you use the query feature within iD (which uses the Overpass API) and point 
at a commercial building you get a Bulgarian label in the results set instead 
of an English one: Търговска Сграда, which translates as "commercial building" 
- there might be other cosmetic bugs out there.

Regards,
Paul



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


[talk-cz] lávka podél břehu

2020-09-16 Thread Petr Vozdecký

Ahoj,

ani jsem se nepodíval, zda to už někdo neudělal, ale pokud ne, tak jak byste
tagovali tuto lávku pro pěší na Brněnské přehradě vč. nově postavených
schodů. Vše je na povrchu terénu jen pro zpevnění, nejde o lávku typu
"most". - viz https://imgbox.com/EiY9Vvhb




Pro úplnost- úsek je zavřený, bude teprve zprovozněno. Termín jsem na první
dobrou nikde nenalezl...





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


Re: [talk-cz] lávka podél břehu

2020-09-16 Thread Jan Dudík
Podobný úsek v Rakousku je tagován jako most
https://www.openstreetmap.org/way/450663550

JAnD
---


st 16. 9. 2020 v 9:42 odesílatel Petr Vozdecký  napsal:

> Ahoj,
> ani jsem se nepodíval, zda to už někdo neudělal, ale pokud ne, tak jak
> byste tagovali tuto lávku pro pěší na Brněnské přehradě vč. nově
> postavených schodů. Vše je na povrchu terénu jen pro zpevnění, nejde o
> lávku typu "most". - viz https://imgbox.com/EiY9Vvhb
>
> Pro úplnost- úsek je zavřený, bude teprve zprovozněno. Termín jsem na
> první dobrou nikde nenalezl...
>
> vop
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz


Re: [Talk-GB] Overpass query strangeness within iD

2020-09-16 Thread Nick
Just out of curiosity, were these all mapped with the new version of the 
RapiD OSM editor https://mapwith.ai/rapid-esri?


On 16/09/2020 08:18, Gareth L wrote:


Morning Mateusz,

You’re right, it’s not encountered in edit mode.

4:

 1. “en-GB en”
 2. “en-GB”
 3. System Locale: en-us;English (United States)*

Input Locale: en-gb;English (United Kingdom)

*damn, i’m normally better at keeping it en-gb!

Gareth

Sent from Mail  for 
Windows 10


*From: *Mateusz Konieczny 
*Sent: *16 September 2020 08:09
*To: *Gareth L 
*Cc: *Paul Berry ; Talk GB 


*Subject: *Re: [Talk-GB] Overpass query strangeness within iD

1) it is not a bug of default style at all - what is displayed in 
tiles is not related


(both are using OSM data and here similarities end)

2) it is not a Mapnik bug - it is a library used by OSM Carto (default 
map style)


3) it is not in edit mode, so it is likely not an iD bug (maybe it 
uses an iD


presets that have some bug)

Is it still visible in edit mode? The it may be an iD bug.

4) Which exactly language settings you have?

(a) In OSM settings

(b) In browser

(c) In OS

For me this is not present,

I see Polish description ("Budynek przemysłowy itp group 
") as I selected


Polish as preferred language in OSM settings.

Sep 16, 2020, 08:57 by o...@live.co.uk:

Hi Paul,

I’m not sure if the fault is with the ID viewer, mapnik, or
overpass-api really. ID bugs can be reported/tracked through its
GitHub repo https://github.com/openstreetmap/iD

For others curious, an example is go to
https://www.openstreetmap.org/#map=19/52.37824/-1.23676
 and
right click> query features on say, the ITP building or air
ambulance. It will show “Индустриална сграда itp group” on the
results where you choose which element you want more detail on.

I’m not that familiar with the codebase but it looks like there
has been quite a lot of activity in the localisation section, so
it is possibly a recently introduced bug.

Gareth

*From: *Paul Berry 

*Sent: *16 September 2020 00:21

*To: *Talk GB 

*Subject: *[Talk-GB] Overpass query strangeness within iD

Hi all,

Not sure who to direct this to so apologies for targeting the
mailing list. However, I hope the right people can be found this way.

If you use the query feature within iD (which uses the Overpass
API) and point at a commercial building you get a Bulgarian label
in the results set instead of an English one: Търговска Сграда,
which translates as "commercial building" - there might be other
cosmetic bugs out there.

Regards,

/Paul/


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


Re: [talk-cz] lávka podél břehu

2020-09-16 Thread Jan Martinec
Ahoj,

Vidím mostní konstrukci, taguju mostní konstrukci.

(Jo, má to minimální až nulovou světlost, ale medle je to most.)

Zdar,
Honza Piškvor Martinec

Dne st 16. 9. 2020 9:42 uživatel Petr Vozdecký  napsal:

> Ahoj,
> ani jsem se nepodíval, zda to už někdo neudělal, ale pokud ne, tak jak
> byste tagovali tuto lávku pro pěší na Brněnské přehradě vč. nově
> postavených schodů. Vše je na povrchu terénu jen pro zpevnění, nejde o
> lávku typu "most". - viz https://imgbox.com/EiY9Vvhb
>
> Pro úplnost- úsek je zavřený, bude teprve zprovozněno. Termín jsem na
> první dobrou nikde nenalezl...
>
> vop
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz


Re: [talk-cz] lávka podél břehu

2020-09-16 Thread Jan Macura
Ahoj,

nevidím, v čem se to liší od povalových chodníků v přírodních rezervacích.
Takže já bych volil bridge=boardwalk
.

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


Re: [Talk-GB] Overpass query strangeness within iD

2020-09-16 Thread Gareth L
Hi Paul,

I’m not sure if the fault is with the ID viewer, mapnik, or overpass-api 
really. ID bugs can be reported/tracked through its GitHub repo 
https://github.com/openstreetmap/iD

For others curious, an example is go to 
https://www.openstreetmap.org/#map=19/52.37824/-1.23676 and right click> query 
features on say, the ITP building or air ambulance. It will show “Индустриална 
сграда itp group” on the results where you choose which element you want more 
detail on.

I’m not that familiar with the codebase but it looks like there has been quite 
a lot of activity in the localisation section, so it is possibly a recently 
introduced bug.

Gareth

From: Paul Berry
Sent: 16 September 2020 00:21
To: Talk GB
Subject: [Talk-GB] Overpass query strangeness within iD

Hi all,

Not sure who to direct this to so apologies for targeting the mailing list. 
However, I hope the right people can be found this way.

If you use the query feature within iD (which uses the Overpass API) and point 
at a commercial building you get a Bulgarian label in the results set instead 
of an English one: Търговска Сграда, which translates as "commercial building" 
- there might be other cosmetic bugs out there.

Regards,
Paul

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


Re: [Talk-GB] Overpass query strangeness within iD

2020-09-16 Thread Mateusz Konieczny via Talk-GB
Have you set Bulgarian as a preferred language in OSM settings?

Are you using browser in Bulgarian language?

Have you set Bulgarian as preferred language in browser?

"query feature within iD (which uses the Overpass API)" - which 
part of iD is using Overpass API? Can you be more specific?

Are you maybe talking about query feature on the OSM page
used without going into edit mode?

If it is an actual iD bug then it would be worth reporting it at
https://github.com/openstreetmap/iD

Sep 16, 2020, 01:20 by pmberry2...@gmail.com:

> Hi all,
>
> Not sure who to direct this to so apologies for targeting the mailing list. 
> However, I hope the right people can be found this way.
>
> If you use the query feature within iD (which uses the Overpass API) and 
> point at a commercial building you get a Bulgarian label in the results set 
> instead of an English one: Търговска Сграда, which translates as "commercial 
> building" - there might be other cosmetic bugs out there.
>
> Regards,
> Paul
>

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


Re: [talk-cz] dotaz ke zmenam v MNE

2020-09-16 Thread jozka
Asi jsem prilis jednoduchy, ale ani s napovedou jsem neprisel jak to primet 
cokoliv udelat...

J.

__
> Od: "majkaz" 
> Komu: "OpenStreetMap Czech Republic" 
> Datum: 15.09.2020 15:19
> Předmět: Re: [talk-cz] dotaz ke zmenam v MNE
>
>Na https://simon04.dev.openstreetmap.org/whodidit/ 
> si najdi to místo, přibliž 
>si to co nejvíc půjde, abys toho neprohledával moc. A zobraz si období 
>"eternity".
> 
>Majka
>__
>> Od: jo...@razdva.cz
>> Komu: talk-cz@openstreetmap.org
>> Datum: 15.09.2020 14:54
>> Předmět: [talk-cz] dotaz ke zmenam v MNE
>>
>Ahoj,
> 
> mam takovy dotaz, ted jsem nahodou zjistil, ze maly kempik u more v MNE, kde 
> jsem pred casem byl na dovolene zmizel z mapy. Podle jejich stranek to 
> nevypada, ze by to zabalili, pochybuji, ze by v takovem pripade nechali bezet 
> stranky a smazali se v OSM, kam jsem je pred lety daval mozna i ja, uz si 
> nepamatuji. Jak zjistim kdy a kdo tu zmenu udelal?
> 
> diky
> J.
> 
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz 
> 
> https://openstreetmap.cz/talkcz 
>
>
>
>--
>
>___
>talk-cz mailing list
>talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz
>https://openstreetmap.cz/talkcz
>
>

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


Re: [Talk-GB] Overpass query strangeness within iD

2020-09-16 Thread Nick via Talk-GB

Hi Gareth

It was just a thought if that might have been the source

Cheers

Nick

On 16/09/2020 10:12, Gareth L wrote:

Hi Nick,

Not in the example I cited.

Gareth


On 16 Sep 2020, at 10:03, Nick  wrote:



Just out of curiosity, were these all mapped with the new version of 
the RapiD OSM editor https://mapwith.ai/rapid-esri?


On 16/09/2020 08:18, Gareth L wrote:


Morning Mateusz,

You’re right, it’s not encountered in edit mode.

4:

 1. “en-GB en”
 2. “en-GB”
 3. System Locale: en-us;English (United States)*

Input Locale: en-gb;English (United Kingdom)

*damn, i’m normally better at keeping it en-gb!

Gareth

Sent from Mail  for 
Windows 10


*From: *Mateusz Konieczny 
*Sent: *16 September 2020 08:09
*To: *Gareth L 
*Cc: *Paul Berry ; Talk GB 


*Subject: *Re: [Talk-GB] Overpass query strangeness within iD

1) it is not a bug of default style at all - what is displayed in 
tiles is not related


(both are using OSM data and here similarities end)

2) it is not a Mapnik bug - it is a library used by OSM Carto 
(default map style)


3) it is not in edit mode, so it is likely not an iD bug (maybe it 
uses an iD


presets that have some bug)

Is it still visible in edit mode? The it may be an iD bug.

4) Which exactly language settings you have?

(a) In OSM settings

(b) In browser

(c) In OS

For me this is not present,

I see Polish description ("Budynek przemysłowy itp group 
") as I selected


Polish as preferred language in OSM settings.

Sep 16, 2020, 08:57 by o...@live.co.uk:

Hi Paul,

I’m not sure if the fault is with the ID viewer, mapnik, or
overpass-api really. ID bugs can be reported/tracked through its
GitHub repo https://github.com/openstreetmap/iD


For others curious, an example is go to
https://www.openstreetmap.org/#map=19/52.37824/-1.23676 and
right click> query features on say, the ITP building or air
ambulance. It will show “Индустриална сграда itp group” on the
results where you choose which element you want more detail on.

I’m not that familiar with the codebase but it looks like there
has been quite a lot of activity in the localisation section, so
it is possibly a recently introduced bug.

Gareth

*From: *Paul Berry 

*Sent: *16 September 2020 00:21

*To: *Talk GB 

*Subject: *[Talk-GB] Overpass query strangeness within iD

Hi all,

Not sure who to direct this to so apologies for targeting the
mailing list. However, I hope the right people can be found this
way.

If you use the query feature within iD (which uses the Overpass
API) and point at a commercial building you get a Bulgarian
label in the results set instead of an English one: Търговска
Сграда, which translates as "commercial building" - there might
be other cosmetic bugs out there.

Regards,

/Paul/


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

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


Re: [talk-au] PSMA Administrative Boundaries

2020-09-16 Thread Andrew Davidson

On 15/9/20 10:53 pm, Andrew Harvey wrote:


1. psma:loc_pid. Where this is a stable ID that is used as a reference, 
the existing ref tag is better for this. If we want to be more specific 
then ref:psma or something like that would work. No need to invent new 
tags here when one already exists, is well documented and in widespread use.


I've never really considered these to be more than tagging for dataset 
maintainers, I didn't really think that any data consumers would want to 
use these. I would not put these under ref=* as they aren't really 
references that end users would see.


The two options would be:
1. the ref: namespace or
2. ref:AU: namespace which is similar to what the FR community seems to use:

https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales

Any opinions?

If this is how people would like to tag these types of ids I would also 
have to go back and modify all of the others I have created over the years.


2. Regarding source tags on objects, this might be something I added 
originally, I can't remember, but I'm on the fence about it.


The majority view at the time that we discussed this was to add a source 
tag. I understand that the source tag does have a decay function as to 
it's usefulness but it's still better than changeset tagging, which 
become useless the moment you upload the data. Maybe if Overpass could 
search for something based on the changeset tags of the last modifying 
changeset they would be useful, but till that tag I prefer to have them 
in-channel.


If the general view is now that adding a source tag is not worthwhile 
then we can leave them out.


The "import" upload 
should immediately be correct and not a broken state until post-import 
changes clean things up, it should be uploaded clean in the first 
instance.


I agree with you 100%. The reason the current workflow has us deleting 
the outer ways before uploading is because this is what you wanted:


https://lists.openstreetmap.org/pipermail/talk-au/2018-October/012131.html

I'm happy to upload valid boundaries which is what I suggested:

https://lists.openstreetmap.org/pipermail/talk-au/2018-October/012132.html

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


Re: [Talk-GB] Overpass query strangeness within iD

2020-09-16 Thread Gareth L
Hi Nick,

Not in the example I cited.

Gareth

On 16 Sep 2020, at 10:03, Nick  wrote:



Just out of curiosity, were these all mapped with the new version of the RapiD 
OSM editor https://mapwith.ai/rapid-esri?

On 16/09/2020 08:18, Gareth L wrote:
Morning Mateusz,

You’re right, it’s not encountered in edit mode.

4:

  1.  “en-GB en”
  2.  “en-GB”
  3.  System Locale: en-us;English (United States)*

Input Locale:  en-gb;English (United Kingdom)

*damn, i’m normally better at keeping it en-gb!

Gareth

Sent from Mail for Windows 10

From: Mateusz Konieczny
Sent: 16 September 2020 08:09
To: Gareth L
Cc: Paul Berry; Talk 
GB
Subject: Re: [Talk-GB] Overpass query strangeness within iD

1) it is not a bug of default style at all - what is displayed in tiles is not 
related
(both are using OSM data and here similarities end)
2) it is not a Mapnik bug - it is a library used by OSM Carto (default map 
style)
3) it is not in edit mode, so it is likely not an iD bug (maybe it uses an iD
presets that have some bug)

Is it still visible in edit mode? The it may be an iD bug.

4) Which exactly language settings you have?

(a) In OSM settings
(b) In browser
(c) In OS

For me this is not present,
I see Polish description ("Budynek przemysłowy itp 
group") as I selected
Polish as preferred language in OSM settings.

Sep 16, 2020, 08:57 by o...@live.co.uk:
Hi Paul,

I’m not sure if the fault is with the ID viewer, mapnik, or overpass-api 
really. ID bugs can be reported/tracked through its GitHub repo 
https://github.com/openstreetmap/iD

For others curious, an example is go to 
https://www.openstreetmap.org/#map=19/52.37824/-1.23676 and right click> query 
features on say, the ITP building or air ambulance. It will show “Индустриална 
сграда itp group” on the results where you choose which element you want more 
detail on.

I’m not that familiar with the codebase but it looks like there has been quite 
a lot of activity in the localisation section, so it is possibly a recently 
introduced bug.

Gareth

From: Paul Berry
Sent: 16 September 2020 00:21
To: Talk GB
Subject: [Talk-GB] Overpass query strangeness within iD

Hi all,

Not sure who to direct this to so apologies for targeting the mailing list. 
However, I hope the right people can be found this way.

If you use the query feature within iD (which uses the Overpass API) and point 
at a commercial building you get a Bulgarian label in the results set instead 
of an English one: Търговска Сграда, which translates as "commercial building" 
- there might be other cosmetic bugs out there.

Regards,
Paul






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


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


Re: [Talk-GB] Overpass query strangeness within iD

2020-09-16 Thread Paul Berry
Sorry, I wasn't in edit mode so nothing to do with iD. I'm using the
latest version of Chrome on Windows 10 and browsing to the standard
https://www.openstreetmap.org site with Standard Layer selected and the
Query tool used. You can see that everything's in en-gb (as I have set it),
excepting the one search result in question, by viewing the screenshot
here: http://pberry.me.uk/osm/osm_query.png

I've double-checked on other devices, operating systems, and browsers but
the issue remains. I hope this helps to narrow down the problem.

Regards,
*Paul*

On Wed, 16 Sep 2020 at 11:04, Nick via Talk-GB 
wrote:

> Hi Gareth
>
> It was just a thought if that might have been the source
>
> Cheers
>
> Nick
> On 16/09/2020 10:12, Gareth L wrote:
>
> Hi Nick,
>
> Not in the example I cited.
>
> Gareth
>
> On 16 Sep 2020, at 10:03, Nick  
> wrote:
>
> 
>
> Just out of curiosity, were these all mapped with the new version of the
> RapiD OSM editor https://mapwith.ai/rapid-esri?
> On 16/09/2020 08:18, Gareth L wrote:
>
> Morning Mateusz,
>
>
>
> You’re right, it’s not encountered in edit mode.
>
>
>
> 4:
>
>1. “en-GB en”
>2. “en-GB”
>3. System Locale: en-us;English (United States)*
>
> Input Locale:  en-gb;English (United Kingdom)
>
>
>
> *damn, i’m normally better at keeping it en-gb!
>
>
>
> Gareth
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> *From: *Mateusz Konieczny 
> *Sent: *16 September 2020 08:09
> *To: *Gareth L 
> *Cc: *Paul Berry ; Talk GB
> 
> *Subject: *Re: [Talk-GB] Overpass query strangeness within iD
>
>
>
> 1) it is not a bug of default style at all - what is displayed in tiles is
> not related
>
> (both are using OSM data and here similarities end)
>
> 2) it is not a Mapnik bug - it is a library used by OSM Carto (default map
> style)
>
> 3) it is not in edit mode, so it is likely not an iD bug (maybe it uses an
> iD
>
> presets that have some bug)
>
>
>
> Is it still visible in edit mode? The it may be an iD bug.
>
>
>
> 4) Which exactly language settings you have?
>
>
>
> (a) In OSM settings
>
> (b) In browser
>
> (c) In OS
>
>
>
> For me this is not present,
>
> I see Polish description ("Budynek przemysłowy itp group
> ") as I selected
>
> Polish as preferred language in OSM settings.
>
>
>
> Sep 16, 2020, 08:57 by o...@live.co.uk:
>
> Hi Paul,
>
>
>
> I’m not sure if the fault is with the ID viewer, mapnik, or overpass-api
> really. ID bugs can be reported/tracked through its GitHub repo
> https://github.com/openstreetmap/iD
>
>
>
> For others curious, an example is go to
> https://www.openstreetmap.org/#map=19/52.37824/-1.23676 and right click>
> query features on say, the ITP building or air ambulance. It will show 
> “Индустриална
> сграда itp group” on the results where you choose which element you want
> more detail on.
>
>
>
> I’m not that familiar with the codebase but it looks like there has been
> quite a lot of activity in the localisation section, so it is possibly a
> recently introduced bug.
>
>
>
> Gareth
>
>
>
> *From: *Paul Berry 
>
> *Sent: *16 September 2020 00:21
>
> *To: *Talk GB 
>
> *Subject: *[Talk-GB] Overpass query strangeness within iD
>
>
>
> Hi all,
>
>
>
> Not sure who to direct this to so apologies for targeting the mailing
> list. However, I hope the right people can be found this way.
>
>
>
> If you use the query feature within iD (which uses the Overpass API) and
> point at a commercial building you get a Bulgarian label in the results set
> instead of an English one: Търговска Сграда, which translates as
> "commercial building" - there might be other cosmetic bugs out there.
>
>
>
> Regards,
>
> *Paul*
>
>
>
>
>
>
>
> ___
> Talk-GB mailing 
> listTalk-GB@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-gb
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Overpass query strangeness within iD

2020-09-16 Thread Tom Hughes via Talk-GB

That would be because somebody on TranslateWiki has added a bunch
of bogus strings to the en-GB translation:

https://github.com/openstreetmap/openstreetmap-website/blob/master/config/locales/en-GB.yml#L621

Tom

On 16/09/2020 12:00, Paul Berry wrote:
Sorry, I wasn't in edit mode so nothing to do with iD. I'm using the 
latest version of Chrome on Windows 10 and browsing to the standard 
https://www.openstreetmap.org site with Standard Layer selected and the 
Query tool used. You can see that everything's in en-gb (as I have set 
it), excepting the one search result in question, by viewing the 
screenshot here: http://pberry.me.uk/osm/osm_query.png


I've double-checked on other devices, operating systems, and browsers 
but the issue remains. I hope this helps to narrow down the problem.


Regards,
/Paul/

On Wed, 16 Sep 2020 at 11:04, Nick via Talk-GB 
mailto:talk-gb@openstreetmap.org>> wrote:


Hi Gareth

It was just a thought if that might have been the source

Cheers

Nick

On 16/09/2020 10:12, Gareth L wrote:

Hi Nick,

Not in the example I cited.

Gareth


On 16 Sep 2020, at 10:03, Nick 
 wrote:



Just out of curiosity, were these all mapped with the new version
of the RapiD OSM editor https://mapwith.ai/rapid-esri?

On 16/09/2020 08:18, Gareth L wrote:


Morning Mateusz,

__ __

You’re right, it’s not encountered in edit mode.

__ __

4:

 1. “en-GB en”
 2. “en-GB”
 3. System Locale: en-us;English (United States)*

Input Locale: en-gb;English (United Kingdom)

__ __

*damn, i’m normally better at keeping it en-gb!

__ __

Gareth

__ __

Sent from Mail 
for Windows 10

__ __

*From: *Mateusz Konieczny 
*Sent: *16 September 2020 08:09
*To: *Gareth L 
*Cc: *Paul Berry ; Talk GB

*Subject: *Re: [Talk-GB] Overpass query strangeness within iD

__ __

1) it is not a bug of default style at all - what is displayed
in tiles is not related

(both are using OSM data and here similarities end)

2) it is not a Mapnik bug - it is a library used by OSM Carto
(default map style)

3) it is not in edit mode, so it is likely not an iD bug (maybe
it uses an iD 

presets that have some bug)

__ __

Is it still visible in edit mode? The it may be an iD bug.

__ __

4) Which exactly language settings you have? 

__ __

(a) In OSM settings

(b) In browser

(c) In OS

__ __

For me this is not present,

I see Polish description ("Budynek przemysłowy itp group
") as I selected

Polish as preferred language in OSM settings.

__ __

Sep 16, 2020, 08:57 by o...@live.co.uk :

Hi Paul,

I’m not sure if the fault is with the ID viewer, mapnik, or
overpass-api really. ID bugs can be reported/tracked through
its GitHub repo https://github.com/openstreetmap/iD


For others curious, an example is go to
https://www.openstreetmap.org/#map=19/52.37824/-1.23676 and
right click> query features on say, the ITP building or air
ambulance. It will show “Индустриална сграда itp group” on
the results where you choose which element you want more
detail on.

I’m not that familiar with the codebase but it looks like
there has been quite a lot of activity in the localisation
section, so it is possibly a recently introduced bug.

Gareth

*From: *Paul Berry 

*Sent: *16 September 2020 00:21

*To: *Talk GB 

*Subject: *[Talk-GB] Overpass query strangeness within iD

Hi all,

Not sure who to direct this to so apologies for targeting
the mailing list. However, I hope the right people can be
found this way.

If you use the query feature within iD (which uses the
Overpass API) and point at a commercial building you get a
Bulgarian label in the results set instead of an English
one: Търговска Сграда, which translates as "commercial
building" - there might be other cosmetic bugs out there.

Regards,

/Paul/

__ __

__ __


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

___
Talk-GB mailing list
Talk-GB@openstreetmap.org 

[talk-au] Admin_level discussion for Australia

2020-09-16 Thread Ewen Hill
Thank you Andrew H for your un-waivering (sic) efforts and changing the
entire way the Australian map is developing. Chapeau!

Andrew's last message in part, discussed how the admin_levels are defined
as and prompted for some suggestions, namely level 9 and 10 and if we
should include electoral boundaries.

I have set up a quick spreadsheet outlining the admin_levels and I think I
have transcribed Andrew's thoughts on how it may work and added mine.

Feel free to add your preferred layout in the next available col and add a
comment if you wish.

https://docs.google.com/spreadsheets/d/1dzOJoOL6sVLinzqZDcC2wOj-e_2BNz5QFkI-xGnpJXI/edit?usp=sharing

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


Re: [Talk-GB] Overpass query strangeness within iD

2020-09-16 Thread Tom Hughes via Talk-GB

Hopefully I've fixed them on TW for the next update.

Tom

On 16/09/2020 12:44, Tom Hughes via Talk-GB wrote:

That would be because somebody on TranslateWiki has added a bunch
of bogus strings to the en-GB translation:

https://github.com/openstreetmap/openstreetmap-website/blob/master/config/locales/en-GB.yml#L621 



Tom

On 16/09/2020 12:00, Paul Berry wrote:
Sorry, I wasn't in edit mode so nothing to do with iD. I'm using the 
latest version of Chrome on Windows 10 and browsing to the standard 
https://www.openstreetmap.org site with Standard Layer selected and 
the Query tool used. You can see that everything's in en-gb (as I have 
set it), excepting the one search result in question, by viewing the 
screenshot here: http://pberry.me.uk/osm/osm_query.png


I've double-checked on other devices, operating systems, and browsers 
but the issue remains. I hope this helps to narrow down the problem.


Regards,
/Paul/

On Wed, 16 Sep 2020 at 11:04, Nick via Talk-GB 
mailto:talk-gb@openstreetmap.org>> wrote:


    Hi Gareth

    It was just a thought if that might have been the source

    Cheers

    Nick

    On 16/09/2020 10:12, Gareth L wrote:

    Hi Nick,

    Not in the example I cited.

    Gareth


    On 16 Sep 2020, at 10:03, Nick 
     wrote:

    

    Just out of curiosity, were these all mapped with the new version
    of the RapiD OSM editor https://mapwith.ai/rapid-esri?

    On 16/09/2020 08:18, Gareth L wrote:


    Morning Mateusz,

    __ __

    You’re right, it’s not encountered in edit mode.

    __ __

    4:

 1. “en-GB en”
 2. “en-GB”
 3. System Locale: en-us;English (United States)*

    Input Locale: en-gb;English (United Kingdom)

    __ __

    *damn, i’m normally better at keeping it en-gb!

    __ __

    Gareth

    __ __

    Sent from Mail 
    for Windows 10

    __ __

    *From: *Mateusz Konieczny 
    *Sent: *16 September 2020 08:09
    *To: *Gareth L 
    *Cc: *Paul Berry ; Talk GB
    
    *Subject: *Re: [Talk-GB] Overpass query strangeness within iD

    __ __

    1) it is not a bug of default style at all - what is displayed
    in tiles is not related

    (both are using OSM data and here similarities end)

    2) it is not a Mapnik bug - it is a library used by OSM Carto
    (default map style)

    3) it is not in edit mode, so it is likely not an iD bug (maybe
    it uses an iD 

    presets that have some bug)

    __ __

    Is it still visible in edit mode? The it may be an iD bug.

    __ __

    4) Which exactly language settings you have? 

    __ __

    (a) In OSM settings

    (b) In browser

    (c) In OS

    __ __

    For me this is not present,

    I see Polish description ("Budynek przemysłowy itp group
    ") as I selected

    Polish as preferred language in OSM settings.

    __ __

    Sep 16, 2020, 08:57 by o...@live.co.uk :

    Hi Paul,

    I’m not sure if the fault is with the ID viewer, mapnik, or
    overpass-api really. ID bugs can be reported/tracked through
    its GitHub repo https://github.com/openstreetmap/iD
    

    For others curious, an example is go to
    https://www.openstreetmap.org/#map=19/52.37824/-1.23676 and
    right click> query features on say, the ITP building or air
    ambulance. It will show “Индустриална сграда itp group” on
    the results where you choose which element you want more
    detail on.

    I’m not that familiar with the codebase but it looks like
    there has been quite a lot of activity in the localisation
    section, so it is possibly a recently introduced bug.

    Gareth

    *From: *Paul Berry 

    *Sent: *16 September 2020 00:21

    *To: *Talk GB 

    *Subject: *[Talk-GB] Overpass query strangeness within iD

    Hi all,

    Not sure who to direct this to so apologies for targeting
    the mailing list. However, I hope the right people can be
    found this way.

    If you use the query feature within iD (which uses the
    Overpass API) and point at a commercial building you get a
    Bulgarian label in the results set instead of an English
    one: Търговска Сграда, which translates as "commercial
    building" - there might be other cosmetic bugs out there.

    Regards,

    /Paul/

    __ __

    __ __


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

    

Re: [Talk-GB] Overpass query strangeness within iD

2020-09-16 Thread Mateusz Konieczny via Talk-GB
Thanks! I forgot that en-GB can also be translated, so
translation mistakaes may become cause of a problem.

Thanks for a fixing it!


Sep 16, 2020, 13:51 by talk-gb@openstreetmap.org:

> Hopefully I've fixed them on TW for the next update.
>
> Tom
>
> On 16/09/2020 12:44, Tom Hughes via Talk-GB wrote:
>
>> That would be because somebody on TranslateWiki has added a bunch
>> of bogus strings to the en-GB translation:
>>
>> https://github.com/openstreetmap/openstreetmap-website/blob/master/config/locales/en-GB.yml#L621
>>  
>>
>> Tom
>>
>> On 16/09/2020 12:00, Paul Berry wrote:
>>
>>> Sorry, I wasn't in edit mode so nothing to do with iD. I'm using the latest 
>>> version of Chrome on Windows 10 and browsing to the standard 
>>> https://www.openstreetmap.org site with Standard Layer selected and the 
>>> Query tool used. You can see that everything's in en-gb (as I have set it), 
>>> excepting the one search result in question, by viewing the screenshot 
>>> here: http://pberry.me.uk/osm/osm_query.png
>>>
>>> I've double-checked on other devices, operating systems, and browsers but 
>>> the issue remains. I hope this helps to narrow down the problem.
>>>
>>> Regards,
>>> /Paul/
>>>
>>> On Wed, 16 Sep 2020 at 11:04, Nick via Talk-GB >> > wrote:
>>>
>>>     Hi Gareth
>>>
>>>     It was just a thought if that might have been the source
>>>
>>>     Cheers
>>>
>>>     Nick
>>>
>>>     On 16/09/2020 10:12, Gareth L wrote:
>>>
     Hi Nick,

     Not in the example I cited.

     Gareth

>     On 16 Sep 2020, at 10:03, Nick 
>      wrote:
>
>     
>
>     Just out of curiosity, were these all mapped with the new version
>     of the RapiD OSM editor https://mapwith.ai/rapid-esri?
>
>     On 16/09/2020 08:18, Gareth L wrote:
>
>>
>>     Morning Mateusz,
>>
>>     __ __
>>
>>     You’re right, it’s not encountered in edit mode.
>>
>>     __ __
>>
>>     4:
>>
>>  1. “en-GB en”
>>  2. “en-GB”
>>  3. System Locale: en-us;English (United States)*
>>
>>     Input Locale: en-gb;English (United Kingdom)
>>
>>     __ __
>>
>>     *damn, i’m normally better at keeping it en-gb!
>>
>>     __ __
>>
>>     Gareth
>>
>>     __ __
>>
>>     Sent from Mail 
>>     for Windows 10
>>
>>     __ __
>>
>>     *From: *Mateusz Konieczny 
>>     *Sent: *16 September 2020 08:09
>>     *To: *Gareth L 
>>     *Cc: *Paul Berry ; Talk GB
>>     
>>     *Subject: *Re: [Talk-GB] Overpass query strangeness within iD
>>
>>     __ __
>>
>>     1) it is not a bug of default style at all - what is displayed
>>     in tiles is not related
>>
>>     (both are using OSM data and here similarities end)
>>
>>     2) it is not a Mapnik bug - it is a library used by OSM Carto
>>     (default map style)
>>
>>     3) it is not in edit mode, so it is likely not an iD bug (maybe
>>     it uses an iD 
>>
>>     presets that have some bug)
>>
>>     __ __
>>
>>     Is it still visible in edit mode? The it may be an iD bug.
>>
>>     __ __
>>
>>     4) Which exactly language settings you have? 
>>
>>     __ __
>>
>>     (a) In OSM settings
>>
>>     (b) In browser
>>
>>     (c) In OS
>>
>>     __ __
>>
>>     For me this is not present,
>>
>>     I see Polish description ("Budynek przemysłowy itp group
>>     ") as I selected
>>
>>     Polish as preferred language in OSM settings.
>>
>>     __ __
>>
>>     Sep 16, 2020, 08:57 by o...@live.co.uk :
>>
>>     Hi Paul,
>>
>>     I’m not sure if the fault is with the ID viewer, mapnik, or
>>     overpass-api really. ID bugs can be reported/tracked through
>>     its GitHub repo https://github.com/openstreetmap/iD
>>     
>>
>>     For others curious, an example is go to
>>     https://www.openstreetmap.org/#map=19/52.37824/-1.23676 and
>>     right click> query features on say, the ITP building or air
>>     ambulance. It will show “Индустриална сграда itp group” on
>>     the results where you choose which element you want more
>>     detail on.
>>
>>     I’m not that familiar with the codebase but it looks like
>>     there has been quite a lot of activity in the localisation
>>     section, so it 

Re: [OSM-talk-fr] Question sur la formulation d'une demande de données à une Mairie

2020-09-16 Thread Gad Jo
Je suis également très intéressé pour proposer à mon agglo le partage des 
quelques données qu'elle à mis en ligne 

Le September 16, 2020 5:06:43 PM UTC, Water-Map  a écrit :
>Bonjour,
>
>La Mairie d’Avignon a récemment mis à disposition une carte qui recense
>des
>points d'eau potable sur la ville.
>
>https://www.echodumardi.com/actualite/avignon-une-carte-pour-trouver-les-fontaines-et-les-points-deau-de-la-ville/
>
>https://cartes.mairie-avignon.com/cartes/index.php/view/map/?repository=rep=ville_fraiche=00B000TFTTTFF=84144
>
>Est-ce que quelqu'un pourrait m'aider à formuler une demande à la
>Mairie
>d'Avignon de mise en accès libre ces données en citant la licence ODbL
>de
>la bonne façon et un exemple d'un bon format de données que la ville
>pourrait partager qui conviendrait à la communauté et qui ne sera pas
>trop
>compliqué à importer dans OSM ?
>
>Merci en avance,
>
>Stuart
>
>
>https://water-map.org
>*Twitter * - *Facebook
>* - *LinkedIn
>*

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


Re: [OSM-talk-fr] Question sur la formulation d'une demande de données à une Mairie

2020-09-16 Thread Yves P.
> Est-ce que quelqu'un pourrait m'aider à formuler une demande à la Mairie
> d'Avignon de mise en accès libre ces données
>
En cliquant sur un robinet on peut lire "Licence Ouverte (LO)".

Donc pas besoin de faire une demande, tu peux les utiliser en citant la
source.

Si jai tout compris, LO -> ODBL c'est bon, l'inverse non.

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


[OSM-talk-fr] Question sur la formulation d'une demande de données à une Mairie

2020-09-16 Thread Water-Map
Bonjour,

La Mairie d’Avignon a récemment mis à disposition une carte qui recense des
points d'eau potable sur la ville.

https://www.echodumardi.com/actualite/avignon-une-carte-pour-trouver-les-fontaines-et-les-points-deau-de-la-ville/

https://cartes.mairie-avignon.com/cartes/index.php/view/map/?repository=rep=ville_fraiche=00B000TFTTTFF=84144

Est-ce que quelqu'un pourrait m'aider à formuler une demande à la Mairie
d'Avignon de mise en accès libre ces données en citant la licence ODbL de
la bonne façon et un exemple d'un bon format de données que la ville
pourrait partager qui conviendrait à la communauté et qui ne sera pas trop
compliqué à importer dans OSM ?

Merci en avance,

Stuart


https://water-map.org
*Twitter * - *Facebook
* - *LinkedIn
*
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


[Talk-GB] Any UK datasets that we could use with the new (July) version of RapiD OSM editor?

2020-09-16 Thread Rob Nickerson
Hi all,

Am a bit late to this, but hopefully some of you spotted the ESRI/Facebook
announcement in July about the new RapiD editor plus JOSM plugin. If not
see:

https://www.esri.com/arcgis-blog/products/arcgis-living-atlas/mapping/arcgis-data-support-in-osm-editors/

I've started a Loomio thread to see if there are any datasets that might be
worthy of exploring using this tool. Using Loomio so that we can make use
of the tools over there (e.g. voting, ranked preferences, etc) but will
keep an eye on any comments shared here as per usual.

https://www.loomio.org/d/vExqDZyS/which-uk-data-could-be-used-in-the-new-rapid-josm-plugin-

There is a good chance that OSM UK would be able to support with uploading
the data on the ESRI platform if we do decide that there is something worth
using. Also if data needs pre-processing (e.g. several datasets combining)
then we can explore that at the same time (similar to what we were
suggesting at the SotM workshop with combining a few of the recent open
datasets).

So yeah, let me know if you have any suggestions. :-)

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


[talk-au] Namespace for maintenance tags

2020-09-16 Thread Andrew Davidson

On 15/9/20 10:53 pm, Andrew Harvey wrote:


1. psma:loc_pid. Where this is a stable ID that is used as a reference, 
the existing ref tag is better for this. If we want to be more specific 
then ref:psma or something like that would work. No need to invent new 
tags here when one already exists, is well documented and in widespread use.




I have been pondering this further and I'm wondering if these type of 
maintenance tags would be more appropriate in the note namespace. So:


note:*=*

rather than

ref:*=*

as note=* is for information for other mappers.

Any thoughts/objections/counter proposals?

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