Re: [Talk-GB] Open route service update

[Richard Fairhurst]

Rob Nickerson wrote:
> A few months ago I spotted an edit where a company employee was 
> moving height restriction data from nodes to ways. This in itself is 
> not wrong

Absolutely - the restriction is much better tagged on the way. It's a
property of the road just like a speed limit or surface, which we also tag
on the way; and as the 'over' bridge itself is tagged as a way, it seems
anomalous not to tag the 'under' way.

Certainly OSRM doesn't, and can't, parse maxheight on nodes. A quick look
through the Graphhopper source suggests its truck profiles expect way
tagging too, though I'm no Java expert and may have missed something.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Great-Britain-f5372682.html

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

Re: [Talk-GB] OSM UK: Updates from November

[Rob Nickerson]

All,

The Advisory Board has now published this [1]. We have already had one
person respond in a way that makes it appear like it is a vote between the
two documents. May I re-iterate that this on it's own is not helpful. The
aim is to gather discussion responses that can aid further the OSMF
designed process. Therefore if you do comment then please provide some
context. This way the DWG and/or OSMF board can fully consider your
comments during the next stage of agreeing a policy. In dev terminology
"pull request" type comments on either documents are also good here.

[1]
https://lists.openstreetmap.org/pipermail/osmf-talk/2017-December/004865.html

Thank you,
*Rob*

On 2 December 2017 at 16:57, Rob Nickerson 
wrote:

> Hi all,
>
> The latest OSM UK C.I.C newsletter just went out (see below/attached). You
> receive this if you are a member of the organisation or signed up to the
> newsletter via https://osmuk.org/join-our-newsletter/
>
> The Advisory Board topic is a bit of a pain in the backside due to poor
> timing so I thought it best to raise it here. As you may or may not be
> aware the OSMF have tasked the Data Working Group (DWG) with writing a
> policy for organised editing. The Advisory Board (AB) pulled our thoughts
> together way back in October but because we are a relatively new group (had
> our first phone meeting last week) we didn't get it across the line in time
> to feed in to the DWGs work. Despite this, it looks like the AB will go
> ahead and share its proposal/thought/guidelines in the coming days. This
> could appear to be quite jarring with the DWG but we have the same aim
> (i.e. to make OSM better) so hopefully it will spark some useful discussion.
>
> Disclosure 1: I am a AB member and fed in to the text in October.
> Disclosure 2: There is a link via the OSMF board between the DWG and the
> AB so the AB's work _may_ have fed in to the DWGs but neither party
> officially spoke. As noted this is due to the fact that AB is relatively
> new rather than any desire to undermine each other.
>
> Thanks,
> *Rob*
>
> -- Forwarded message --
> From: OSM UK 
> Date: 2 December 2017 at 16:32
> Subject: OSM UK: Updates from November
> To: rob.j.nicker...@gmail.com
>
>
> November has been a busy month - read on to find out why
> Geospatial Commission When the Chancellor presented his Autumn Budget to
> Parliament it included the announcement
> 
> of a new Geospatial Commission tasked with maximising the value of all UK
> government data linked to location. We are super excited about what this
> can mean for OSM and are looking forward to getting involved
> 
> where we can.
>   AGM locations Its a long time until our next AGM but planning has
> already started. We would like to know your preference of location. Please
> complete our loomio poll
> .
> Not yet on Loomio? Sign up today - it only takes 2 minutes.
>   Community validation tool Over on the talk-gb mailing list there has
> been a lot of discussion about how best to add third party Shell petrol
> station data to OSM. Based on your feedback Ilya has developed a Community
> Validation tool
> .
> We'd like your view on this - is it an example that we can share as good
> practice? Let us know here
> 
> .
>   Advisory Board Rob has now taken his seat on OSMF's Advisory Board
> 
> which currently includes 5 corporate members and 5 local chapter
> representatives. Although relatively new the proposed Directed Editing
> Policy
> 
> has given us something to discuss. We drafted a proposal based on the
> groups experience way back in October but didn't manage to share it in time.
>
> Despite the bad timing the group is likely to publish its guideline. The
> hope is to continue the discussion around organised editing with the goal
> of eventually converging on a common set of best practices. Once published
> it would be good to do a compare and contrast - for example, how do they
> effect you?
> Best regards,
>
> *Your OSM UK Directors (Adam Hoyle, Brian Prangle, Gregory Marler, Jon
> Harley & Rob Nickerson)*
> *Copyright © 2017 OSM UK, All rights reserved.*
> You are receiving this email because you opted in at our website or a
> previous survey.
>
> *Our mailing address is:*
> OSM UK
> 132 Maney Hill Road
> 

[Talk-GB] Open route service update

[Rob Nickerson]

Hi all,

A success story:

A few months ago I spotted an edit where a company employee was moving
height restriction data from nodes to ways. This in itself is not wrong but
it could lead to errors if rushed (as it was in this case). It also felt
like editing for the routing engine.

I investigated and found that the routing engine was Open route service. I
therefore submitted a request:

> Would it be possible to make Openrouteservice understand height
restrictions mapped on nodes [1] in the same way that it understands
barriers mapped on nodes [2].

Today I was informed that this change would be made :-). This will save the
company employee time and reduce the risk that errors are introduced in to
OSM.

[1] https://openrouteservice.org/directions?n1=52.285527&n2=-1.5
93833&n3=16&a=52.285934,-1.595807,52.287299,-1.598339&b=4a&
c=0&f3=5&k1=en-US&k2=km
[2] https://openrouteservice.org/directions?n1=52.28235&n2=-1.59
3125&n3=16&a=52.283893,-1.594627,52.281254,-1.595174&b=0&c=0&k1=en-US&k2=km

Best regards,
*Rob*
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Importing Shell fuel stations

[Ilya Zverev]

Hi,

I've just pushed a big update to the auditing service. You can now re-check 
skipped objects. But the "skipped" flag is only stored since today. If you 
want, Brian, I can reset your validation history for the entire project, so you 
could re-check all stations.

Also I can grant you admin rights when you have a osm_conflate json file ready 
to be validated.

We are just 130 stations away from the import being fully checked: 
http://audit.osmz.ru/project/shell

Rob, I agree that the amenity=fuel tag should go on a territory, not on 
individual objects. That would be in line with other amenity values: school, 
university, parking, place_of_worship etc.

Robert, when you find a phone on an amenity=fuel object, you use it to call not 
a fuel pump and not a building. Amenity=fuel marks not a physical object, it is 
an abstract entity called "fuel station", with pumps, service roads, buildings 
and shops. Thus, all the extra properties, like phone or website, should go 
along the amenity=fuel tag, and not be placed on elements of its infrastructure.

When you map a fuel station with a node, it does not matter where exactly it is 
placed. The point is, when a driver plots a route to a fuel station, they 
should get to the entrance of it, and the rest does not matter. Mapping a 
station as a polygon places the virtual station point anywhere inside that 
polygon — but that, again, does not matter in practical use.

Ilya

> 8 дек. 2017 г., в 18:43, Brian Prangle  написал(а):
> 
> Hi Ilya
> 
> Great tool but it would be nice to be able to be able togo back to items you 
> skipped
> 
> Regards
> 
> Brian
> 
> On 29 November 2017 at 14:49, Ilya Zverev  wrote:
> Hi Phil,
> 
> I had a few free hours today, so I added the table view:
> 
> http://audit.osmz.ru/table/shell
> 
> Though I'm not sure a fuel station cannot close at 16:00 — for example, a 
> small one that serves agricultural needs.
> 
> Ilya
> 
> > 26 нояб. 2017 г., в 17:52, Philip Barnes  написал(а):
> >
> > On Sun, 2017-11-26 at 16:46 +0300, Ilya Zverev wrote:
> >> Hi Rob, thanks for looking at the website.
> >>
> >> Perhaps I wasn't clear enough. That is a working tool for validating
> >> an import. Please open http://audit.osmz.ru/project/shell , click
> >> "Validate the import" and check at least a hundred points. You can
> >> move a point when it's off, and you can choose which tags go on an
> >> object.
> >>
> >> If you remember writing me about some of the fuel stations, please
> >> find these on the "browse points" screen, click "edit this" and put
> >> changes there.
> >>
> >> I'll plan to do the import when at least a half of the points have
> >> been looked at — depending on a speed. I will check a few hundred
> >> myself, but me being not in UK, I doubt it would help increase the
> >> quality.
> >>
> > Would it be possible to display this import in a table form, a line for
> > each object and a column for each tag?
> >
> > This would make obvious errors easier to spot, one example I found was
> > a closing time of 16:00 which is an obvious error that does not need
> > local knowledge.
> >
> > Thanks
> > Phil (trigpoint)
> >
> > ___
> > 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