Re: [Talk-GB] ref:hectares on admin boundary, and non-responsive mapper

[Dave F]

On 16/08/2016 17:28, Colin Smale wrote:


Dave, if the is_in values are based on common usage rather than 
administrative reality, then it would actually be correct to leave 
them unchanged.




If a better way of doing something is created then the old methods 
become redundant & should be removed for the reasons Andy Allan 
mentioned in a previous post in this thread. Sarah Hoffmann's reply in 
the Talk thread I posted clearly says is_in:* "is unnecessary"


The point I am trying to make, is that I see a need to support a 
variety of addressing/location systems, which are all correct in their 
own way, but useful for different things.




As far as I can see is_in:* is used for the same things as boundaries, 
but is less efficient & prone to errors.


Are you aware of any utilities that use is_in:*?

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

Re: [Talk-GB] ref:hectares on admin boundary, and non-responsive mapper

[Andy Townsend]

On 16/08/2016 21:57, Colin Smale wrote:


Having just received another "too busy mapping" response to a 
changeset comment I have requested DWG to give alexkemp a 0-minute 
block to remind him of his duty to engage with the community in a 
proper way.




We (the Data Working Group) normally use 0-hour blocks as a "message 
that has to be read" for people who may have misconfigured email, to 
make sure that messages really are being seen by the mapper concerned.  
I normally end up writing a sentence along the lines of "... you'll be 
able to continue mapping immediately after reading this" just to make it 
clear that it's not a block as such (temporary or permanent).


I don't believe that a 0-hour block is appropriate in this case as 
there's no evidence that messages aren't being read (actions would 
suggest that they are).  Following up on previous messages to Alex I've 
added a discussion comment to 
http://www.openstreetmap.org/changeset/41481784 asking for the "out of 
office" messages not to be sent.


Obviously what we want to happen is to get everyone's engagement with 
how and why boundaries have been mapped as they are so far, and I've 
suggested that the talk-gb list is probably the best place for that 
(there's also the East Mids pub meetup in Derby next week, where a 
number of the protagonists will be present).  The more general point is 
(and this is a line that appears in many of the DWG messages that I 
send) that OSM is a collaborative project, and we need to work together 
to create the best map.  This doesn't mean that "the way that it is done 
now" is always right, but it does mean listening to other people, and a 
discussion putting across all points of view needs to be had.  It's 
worth pointing out that the discussion so far has certainly been useful 
to me, not least in learning that "is_in" is processed by Nominatim (to 
an extent at least - see 
https://lists.openstreetmap.org/pipermail/talk/2016-August/076596.html 
et al).


On a more general point one of the things that is often a surprise and a 
frustration to people and companies coming into OSM anew (especially 
companies) is that everything moves quite slowly - it's about creating a 
Canaletto rather than Sid from down the road applying a couple of coats 
of Dulux.  I suspect that that the speed perception might be a factor 
here too.


Best Regards,

Andy Townsend (SomeoneElse)




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

Re: [Talk-GB] ref:hectares on admin boundary, and non-responsive mapper

[Colin Smale]

Having just received another "too busy mapping" response to a changeset
comment I have requested DWG to give alexkemp a 0-minute block to remind
him of his duty to engage with the community in a proper way. 

Colin

On 2016-08-16 14:55, Dave F wrote:

> +1
> 
> Also his use of is_in:* is also redundant when the boundary tag is used,
> 
> Dave F.
> 
> On 16/08/2016 13:25, Andy Allan wrote: On 16 August 2016 at 13:11, Will 
> Phillips  wrote:
> 
> Regarding the 'ref:hectares' tag, it does seem wrong to me. It's not
> consistent with other uses of the ref tag in OSM. Also, I agree that tagging
> area values seems redundant, but perhaps doesn't do any harm in this case. I
> do think at least, they should be retagged, perhaps to area:ha or
> area:hectares? No, they should be removed.
> 
> While it seems like tags like this do little harm, they encourage
> future importers to follow the same path, and our database ends up
> full of cruft. It's also off-putting to mappers, who might be scared
> off from fixing the geometry of features since they don't know how to
> recalculate the area.
> 
> There's no good reason to keep them.
> 
> Thanks,
> Andy
> 
> ___
> 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] Possible use of OS triangulation stations to determine aerial imagery offset

[David Woolley]

On 16/08/16 15:22, Greg wrote:

There is also a FOI request with a full CSV file here:


FOI responses don't remove any copyright and I don't think they even 
given any right to republish the data.


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

Re: [Talk-GB] ref:hectares on admin boundary, and non-responsive mapper

[Colin Smale]

Dave, if the is_in values are based on common usage rather than
administrative reality, then it would actually be correct to leave them
unchanged. 

The point I am trying to make, is that I see a need to support a variety
of addressing/location systems, which are all correct in their own way,
but useful for different things. In order to do that we need additional
tagging systems, otherwise people will try to force-fit (for example)
postal addresses (postcode sectors, post towns etc) onto administrative
boundaries and the result will be neither fish nor fowl. 

Is Rochester in Kent? Most people would say yes. "Where am I?" (powered
by Nominatim) returns:

* 

Troy Town, Rochester, Medway, South East, England, United Kingdom [1] 

Which while administratively correct (except for Troy Town which is a
suburb, modelled in OSM as a simple node without a defined boundary), is
not particularly useful (IMHO of course) - a more typical human would
expect "Rochester, Kent, England, United Kingdom" 

I am glad you asked about Nominatim's algorithm. I suspect there is an
element of black magic involved. I hope they do not keep it too secret
in order not to encourage "tagging for the renderer" but some insights
would definitely be useful. Then we want to think what we actually
expect Nominatim to return for reverse geocoding. Postal address?
Administrative divisions? Local perception? 

Colin 

On 2016-08-16 17:37, Dave F wrote:

> I queried Alex's rational:
> 
> http://www.openstreetmap.org/user/alexkemp/diary/39062
> 
> As I noted is_in tags are hard-coded so become inaccurate if boundaries 
> change.
> 
> I also asked about Nominatim's search criteria on the Talk forum:
> 
> https://lists.openstreetmap.org/pipermail/talk/2016-August/076592.html
> 
> Dave F.
> 
> On 16/08/2016 16:01, Colin Smale wrote: 
> 
> In the specific case of the UK, I am not convinced that is_in has no value at 
> all. This is because of the huge divergence between people's perceptions and 
> administrative reality. If you ask someone to give their location/current 
> address, they will most likely refer to the postal addressing system, which 
> is completely unconnected to administrative boundaries. They will also tend 
> to add a level of detail to the address which the postal system does not 
> require, but tolerates. The admin boundaries represent the legal status, but 
> it will be more relevant to most people's minds if Nominatim et al. recognise 
> an alternative place hierarchy. I think place=* polygons/nodes may already be 
> used, but the results sometimes seem to be an awful jumble of admin 
> boundaries and place-based info. The fact that large swathes of the 
> countryside are unparished (i.e. no admin_level=10 polygon with a name) makes 
> the quality/accuracy of the results variable according to the location. Alex 
> Kemp is
experimenting with introducing artificial admin_level=10 polygons for these 
unparished areas with names based on historical data to help Nominatim which 
IMHO is not the way to do it. Parishes are useless for navigation/addressing 
anyway. 
> 
> Bottom line is that locations have multiple ways of being defined, and this 
> is not currently embraced by OSM which wants a nice simple address+polygon 
> hierarchy. For many countries that works, but not for the UK. It is possible 
> that the is_in data can give an alternative perspective. BUT it needs to be 
> kept distinct from the admin boundaries, which are a matter of law, and it 
> needs to give complete coverage of the country, which at present is probably 
> not the case. 
> 
> Colin
> 
> On 2016-08-16 14:55, Dave F wrote: 
> +1
> 
> Also his use of is_in:* is also redundant when the boundary tag is used,
> 
> Dave F.
> 
> On 16/08/2016 13:25, Andy Allan wrote: On 16 August 2016 at 13:11, Will 
> Phillips  wrote:
> 
> Regarding the 'ref:hectares' tag, it does seem wrong to me. It's not
> consistent with other uses of the ref tag in OSM. Also, I agree that tagging
> area values seems redundant, but perhaps doesn't do any harm in this case. I
> do think at least, they should be retagged, perhaps to area:ha or
> area:hectares? No, they should be removed.
> 
> While it seems like tags like this do little harm, they encourage
> future importers to follow the same path, and our database ends up
> full of cruft. It's also off-putting to mappers, who might be scared
> off from fixing the geometry of features since they don't know how to
> recalculate the area.
> 
> There's no good reason to keep them.
> 
> Thanks,
> Andy
> 
> ___
> 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

Re: [Talk-GB] ref:hectares on admin boundary, and non-responsive mapper

[Dave F]

I queried Alex's rational:

http://www.openstreetmap.org/user/alexkemp/diary/39062

As I noted is_in tags are hard-coded so become inaccurate if boundaries 
change.


I also asked about Nominatim's search criteria on the Talk forum:

https://lists.openstreetmap.org/pipermail/talk/2016-August/076592.html

Dave F.


On 16/08/2016 16:01, Colin Smale wrote:


In the specific case of the UK, I am not convinced that is_in has no 
value at all. This is because of the huge divergence between people's 
perceptions and administrative reality. If you ask someone to give 
their location/current address, they will most likely refer to the 
postal addressing system, which is completely unconnected to 
administrative boundaries. They will also tend to add a level of 
detail to the address which the postal system does not require, but 
tolerates. The admin boundaries represent the legal status, but it 
will be more relevant to most people's minds if Nominatim et al. 
recognise an alternative place hierarchy. I think place=* 
polygons/nodes may already be used, but the results sometimes seem to 
be an awful jumble of admin boundaries and place-based info. The fact 
that large swathes of the countryside are unparished (i.e. no 
admin_level=10 polygon with a name) makes the quality/accuracy of the 
results variable according to the location. Alex Kemp is experimenting 
with introducing artificial admin_level=10 polygons for these 
unparished areas with names based on historical data to help Nominatim 
which IMHO is not the way to do it. Parishes are useless for 
navigation/addressing anyway.


Bottom line is that locations have multiple ways of being defined, and 
this is not currently embraced by OSM which wants a nice simple 
address+polygon hierarchy. For many countries that works, but not for 
the UK. It is possible that the is_in data can give an alternative 
perspective. BUT it needs to be kept distinct from the admin 
boundaries, which are a matter of law, and it needs to give complete 
coverage of the country, which at present is probably not the case.


Colin

On 2016-08-16 14:55, Dave F wrote:


+1

Also his use of is_in:* is also redundant when the boundary tag is used,

Dave F.

On 16/08/2016 13:25, Andy Allan wrote:
On 16 August 2016 at 13:11, Will Phillips > wrote:



Regarding the 'ref:hectares' tag, it does seem wrong to me. It's not
consistent with other uses of the ref tag in OSM. Also, I agree that tagging
area values seems redundant, but perhaps doesn't do any harm in this case. I
do think at least, they should be retagged, perhaps to area:ha or
area:hectares?

No, they should be removed.

While it seems like tags like this do little harm, they encourage
future importers to follow the same path, and our database ends up
full of cruft. It's also off-putting to mappers, who might be scared
off from fixing the geometry of features since they don't know how to
recalculate the area.

There's no good reason to keep them.

Thanks,
Andy

___
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


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

Re: [Talk-GB] ref:hectares on admin boundary, and non-responsive mapper

[Colin Smale]

In the specific case of the UK, I am not convinced that is_in has no
value at all. This is because of the huge divergence between people's
perceptions and administrative reality. If you ask someone to give their
location/current address, they will most likely refer to the postal
addressing system, which is completely unconnected to administrative
boundaries. They will also tend to add a level of detail to the address
which the postal system does not require, but tolerates. The admin
boundaries represent the legal status, but it will be more relevant to
most people's minds if Nominatim et al. recognise an alternative place
hierarchy. I think place=* polygons/nodes may already be used, but the
results sometimes seem to be an awful jumble of admin boundaries and
place-based info. The fact that large swathes of the countryside are
unparished (i.e. no admin_level=10 polygon with a name) makes the
quality/accuracy of the results variable according to the location. Alex
Kemp is experimenting with introducing artificial admin_level=10
polygons for these unparished areas with names based on historical data
to help Nominatim which IMHO is not the way to do it. Parishes are
useless for navigation/addressing anyway. 

Bottom line is that locations have multiple ways of being defined, and
this is not currently embraced by OSM which wants a nice simple
address+polygon hierarchy. For many countries that works, but not for
the UK. It is possible that the is_in data can give an alternative
perspective. BUT it needs to be kept distinct from the admin boundaries,
which are a matter of law, and it needs to give complete coverage of the
country, which at present is probably not the case. 

Colin

On 2016-08-16 14:55, Dave F wrote:

> +1
> 
> Also his use of is_in:* is also redundant when the boundary tag is used,
> 
> Dave F.
> 
> On 16/08/2016 13:25, Andy Allan wrote: On 16 August 2016 at 13:11, Will 
> Phillips  wrote:
> 
> Regarding the 'ref:hectares' tag, it does seem wrong to me. It's not
> consistent with other uses of the ref tag in OSM. Also, I agree that tagging
> area values seems redundant, but perhaps doesn't do any harm in this case. I
> do think at least, they should be retagged, perhaps to area:ha or
> area:hectares? No, they should be removed.
> 
> While it seems like tags like this do little harm, they encourage
> future importers to follow the same path, and our database ends up
> full of cruft. It's also off-putting to mappers, who might be scared
> off from fixing the geometry of features since they don't know how to
> recalculate the area.
> 
> There's no good reason to keep them.
> 
> Thanks,
> Andy
> 
> ___
> 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

[Talk-GB] Possible use of OS triangulation stations to determine aerial imagery offset

[Greg]

Dear all,

Ordnance Survey has a database of triangulation stations and their
precise locations as OSGB36 (National Grid) co-ordinates publicly
available here:
https://www.ordnancesurvey.co.uk/gps/legacy-control-information/triangulation-stations.
There is also a FOI request with a full CSV file here:
https://www.ordnancesurvey.co.uk/about/governance/foi/questions/2015/0056.html.
I'm not sure under what licence the co-ordinates are published though.

It struck me that accurate co-ordinates for the visible stations such as
church spires, masts and water towers could be helpful in accurately
determining the offset of aerial imagery. It's possible to convert the
CSV to a GPX file with WGS84 lat/lon using QGIS (although I couldn't get
JOSM to display the metadata for each point). The imagery can then be
aligned to these points, bearing in mind of course that the imagery is
often taken from an angle (see
http://wiki.openstreetmap.org/wiki/Roof_modelling#Drawing_of_simple_building_outlines).

Best wishes,
Greg.

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

Re: [Talk-GB] ref:hectares on admin boundary, and non-responsive mapper

[Dave F]

+1

Also his use of is_in:* is also redundant when the boundary tag is used,

Dave F.

On 16/08/2016 13:25, Andy Allan wrote:

On 16 August 2016 at 13:11, Will Phillips  wrote:


Regarding the 'ref:hectares' tag, it does seem wrong to me. It's not
consistent with other uses of the ref tag in OSM. Also, I agree that tagging
area values seems redundant, but perhaps doesn't do any harm in this case. I
do think at least, they should be retagged, perhaps to area:ha or
area:hectares?

No, they should be removed.

While it seems like tags like this do little harm, they encourage
future importers to follow the same path, and our database ends up
full of cruft. It's also off-putting to mappers, who might be scared
off from fixing the geometry of features since they don't know how to
recalculate the area.

There's no good reason to keep them.

Thanks,
Andy

___
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] Defibrillator Mapping

[Andy Townsend]

On 16/08/2016 09:35, Robert Whittaker (OSM lists) wrote:

As in other areas, our mapping of Defibrillators in the East Midlands
doesn't seem to be very complete yet...


Thanks Robert.  The two nearest to me that I'm aware of are actually 
very new - they've only appeared within the last couple of months, so 
it's not too much of a surprise that they haven't been mapped yet.


Cheers,

Andy



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

Re: [Talk-GB] Defibrillator Mapping

[Dave F]

Hi

What a ridiculous response from South West Ambulance Services:

"There is a significant risk arising from a list of community
defibrillators appearing in the public domain..."

Clearly Mr Ken Wenman is unaware that 'community' & 'public' are one & 
the same.


They're even publicly tweeting the locations:
https://twitter.com/swasFT/status/566261258610278400

Dave F.

On 16/08/2016 09:35, Robert Whittaker (OSM lists) wrote:

Just to let you know, that I've now got another dataset in my
Defibrillator comparison tool athttp://robert.mathmos.net/osm/defib/
. East Midlands Ambulance Service has provided the locations of AEDs
that they know about, and these have now been imported into the tool.
As in other areas, our mapping of Defibrillators in the East Midlands
doesn't seem to be very complete yet...

Robert.

On 22 April 2016 at 14:43, Robert Whittaker (OSM lists)
  wrote:

It was suggested that trying to increase our mapping of public
Defibrillators would be a good think. After a bit of digging, it seems
that Ambulance Services typically maintain a list of locations, with a
view to informing people about them if a 999 call comes in nearby
where one might be useful.

The different services seem to take quite different views on these
lists. My local service (East of England) actively publicise their
list 
(http://www.eastamb.nhs.uk/Get-involved/Community-Public-Access-Defibrillators.htm)
on the grounds that raising awareness of the locations will make it
more likely that someone will know about and find a defibrillator in
an emergency. Other services have refused FOI requests on the (IMO
spurious) grounds that publicising the list will make thefts /
vandalism more likely, and out of date information may lead to people
wasting time in an emergency.

Anyway, I've taken the East of England list from
http://www.eastamb.nhs.uk/Get%20involved/CPADs/CPAD%20List.pdf  , and
done a comparison with the OSM data. A rough and ready tool can be
found athttp://robert.mathmos.net/osm/defib/progress/  for any other
locals who want to use it. We've got a small number of locations they
haven't, and some of their postcodes may not be quite right. But there
are a lot on their list that aren't mapped yet!

Regarding tagging, it seems that a lot of the cabinets have a
reference number on the outside, so I'd suggest recording that in the
ref=* tag. Also, I think a description of the location would be useful
(e.g. "Outside wall of McDonalds, facing Store 21") to help people
find the defibrillator when they need it. I've been putting something
like that in a location=* key.

In terms of getting more data, I've put in FOI requests to the East
and West Midlands Ambulance Services for starters, so we'll see what
line they take...



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

Re: [Talk-GB] ref:hectares on admin boundary, and non-responsive mapper

[Will Phillips]

On 15/08/2016 08:39, Colin Smale wrote:


Hi,

I noticed a number of new admin boundaries have been tagged with 
ref:hectares=* with the numeric value giving the area of the entity in 
hectares. This feels to me like an inappropriate use of "ref" and also 
redundant as the area can be calculated simply from the geometry 
anyway. When I queried this with the mapper (user alexkemp) via a 
changeset discussion [1] I got the following response:


"This is an automated response: sorry, but I'm too busy mapping too be 
able to spare the time to respond to you. Thank you for your interest 
in my mapping. -Alex Kemp"


Any thoughts about the tagging?

Any thoughts about engaging the user? There is also a discussion on 
another one of his changesets where he unilaterally diverged from the 
established tagging [2].


Colin

[1] http://www.openstreetmap.org/changeset/41449409

[2] http://www.openstreetmap.org/changeset/41371134

 _



Regarding the 'ref:hectares' tag, it does seem wrong to me. It's not 
consistent with other uses of the ref tag in OSM. Also, I agree that 
tagging area values seems redundant, but perhaps doesn't do any harm in 
this case. I do think at least, they should be retagged, perhaps to 
area:ha or area:hectares?


Will

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

Re: [Talk-GB] Defibrillator Mapping

[Robert Whittaker (OSM lists)]

Just to let you know, that I've now got another dataset in my
Defibrillator comparison tool at http://robert.mathmos.net/osm/defib/
. East Midlands Ambulance Service has provided the locations of AEDs
that they know about, and these have now been imported into the tool.
As in other areas, our mapping of Defibrillators in the East Midlands
doesn't seem to be very complete yet...

Robert.

On 22 April 2016 at 14:43, Robert Whittaker (OSM lists)
 wrote:
> It was suggested that trying to increase our mapping of public
> Defibrillators would be a good think. After a bit of digging, it seems
> that Ambulance Services typically maintain a list of locations, with a
> view to informing people about them if a 999 call comes in nearby
> where one might be useful.
>
> The different services seem to take quite different views on these
> lists. My local service (East of England) actively publicise their
> list 
> (http://www.eastamb.nhs.uk/Get-involved/Community-Public-Access-Defibrillators.htm)
> on the grounds that raising awareness of the locations will make it
> more likely that someone will know about and find a defibrillator in
> an emergency. Other services have refused FOI requests on the (IMO
> spurious) grounds that publicising the list will make thefts /
> vandalism more likely, and out of date information may lead to people
> wasting time in an emergency.
>
> Anyway, I've taken the East of England list from
> http://www.eastamb.nhs.uk/Get%20involved/CPADs/CPAD%20List.pdf , and
> done a comparison with the OSM data. A rough and ready tool can be
> found at http://robert.mathmos.net/osm/defib/progress/ for any other
> locals who want to use it. We've got a small number of locations they
> haven't, and some of their postcodes may not be quite right. But there
> are a lot on their list that aren't mapped yet!
>
> Regarding tagging, it seems that a lot of the cabinets have a
> reference number on the outside, so I'd suggest recording that in the
> ref=* tag. Also, I think a description of the location would be useful
> (e.g. "Outside wall of McDonalds, facing Store 21") to help people
> find the defibrillator when they need it. I've been putting something
> like that in a location=* key.
>
> In terms of getting more data, I've put in FOI requests to the East
> and West Midlands Ambulance Services for starters, so we'll see what
> line they take...


-- 
Robert Whittaker

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