Re: [Talk-GB] Motorway junctions where the slow lane seperates from the through lanes

2020-01-14 Per discussione Paul Jaggard

Hi


I would suggest that the motorway should not be split until the point 
where the two halves physically diverge; instead, where there's a drop 
lane, use turn:lanes and destination:lanes tags to indicatethe presence 
of the drop lane.


My reasoning for this:

- firstly, there's no physical separation between the drop lane and the 
main line of the motorway, and it's still physically and legally 
possible to change between the two, and


- secondly, splitting a motorway based on different lanes having 
different destinations sets an awkward pattern, which taken to extremes 
means we end up splitting roads all over the place based on lane 
markings.  Sometimes that's necessary to make routing work sensibly 
through complex junctions, but I'd argue that this isn't one of those cases.



Best illustrated with examples:

Drop lane starts here.  Before this point, a single way with lanes=3.  
After this point, still a single way, with lanes=3, 
turn:lanes=slight_left|through|through :


https://www.mapillary.com/app/?pKey=v4H-uhxh9QQYjzL1b_BNMg=photo

The drop lane then runs for 300 metres, where there's no physical (or 
legal) barrier between the lanes, so still a single way with lanes=3, 
turn:lanes=slight_left|through|through :


https://www.mapillary.com/app/?pKey=S-dGYQdsR7olODRufbB5bg=photo

Then the actual split, where first there's a legal barrier (solid white 
paint), then a physical one (grass, barrier, trees, hillside, etc):


https://www.mapillary.com/app/?pKey=1WY5HbP5K-vpUnAT0voYGw=photo

It's here where I'd suggest we'd split into highway=motorway_link, 
lanes=1 (lanes=2 shortly thereafter), and highway=motorway, lanes=2, 
with a shortish Y-shaped transition to make it look sensible.  Of 
course, at this point the main line of the motorway loses the turn:lanes 
tag, and you can then add turn:lanes tags to the slip road as it widens 
out for the roundabout at the end.  The middle point of the Y (and not 
the start of the drop lane) carries the highway=motorway_junction and 
associated tags.


You could also add destination:lanes tags to label up the signed 
destinations, and destination:ref:lanes=A4174|M32|M32.



Incidentally, for me, /this/ is the sort of situation justifying 
separate, parallel ways on a motorway: 
https://www.mapillary.com/app/?pKey=AL0RC-DyWe27PMQEAS1uZA=photo



TL;DR?  Don't split based on lane markings, it's not a 300-metre-long 
physically separate way, it's just a lane with a different destination.  
Instead use turn:lanes, destination:lanes and destination:ref:lanes tags 
to indicate the drop lane.



Cheers,


Paul ("southglos")



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


Re: [OSM-talk] shortened names

2011-07-27 Per discussione Paul Jaggard
 From: John Smith deltafoxtrot...@gmail.com
 The period after St. is the correct way in English to abbreviate
 Saint, where as the abbreviation of street doesn't have a period.

Exactly the opposite according to my (Collins) dictionary:

st abbrev. for short ton.
St abbrev. for Saint.
st. abbrev. for stanza, statute, (cricket) stumped by
St. abbrev. for statute, Strait, Street
Sta abbrev. for Saint (female).

Paul.


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


[OSM-talk] OSM Haiti mapping on BBC News website

2010-02-24 Per discussione Paul Jaggard
OSM's Haiti effort gets a BBC News Magazine piece here:
http://news.bbc.co.uk/1/hi/magazine/8517057.stm

...and it's currently featured on the http://news.bbc.co.uk/ front page.

Paul.


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


Re: [Talk-GB] Estimating coverage

2009-08-11 Per discussione Paul Jaggard
Hi

Nice work!

The area figures are obviously including the wet bits.  Bristol is half
water: http://news.bbc.co.uk/1/hi/england/bristol/7019663.stm

I also notice the OSM motorway figures are generally a fair bit above the
official figures - slip roads?

Cheers

Paul (southglos)

-Original Message-
Date: Tue, 11 Aug 2009 10:55:31 +0100
From: Peter Reed peter.r...@aligre.co.uk
Subject: [Talk-GB] Estimating coverage

I thought that comparing the area enclosed by the admin boundary on OSM with
the area published by national statistics would be a good indicator of
whether the boundary was accurate. In practice it works sometimes, but not
others. I think this is mainly because of how the coastline and estuaries
are handled in different places. Bristol is the extreme -the government
thinks it is about twice as big as the area included in the boundary on OSM.




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


Re: [Talk-GB] Counties and coasts

2009-06-23 Per discussione Paul Jaggard

Bristol (City and County) has an interesting boundary - it follows the
bank of the River Avon out to the Severn estuary, then takes a large strip
out of the Bristol Channel down to a pair of islands beyond Cardiff and
Weston-s-M.

Seems that the water off the shore of a fair bit of North Somerset belongs
to Bristol.

A BBC news article about it here:
http://news.bbc.co.uk/1/hi/england/bristol/7019663.stm

I traced the boundary from NPE some time ago based on this, but I notice
that since then someone has redone the Bristol boundary and has removed the
relevant ways, chopping back the water boundary to the end of the Avon.

Paul
(southglos)


-Original Message-

Date: Mon, 22 Jun 2009 14:45:55 +0100
From: Chris Hill chillly...@yahoo.co.uk
Subject: [Talk-GB] Counties and coasts
To: Talk GB talk-gb@openstreetmap.org
Message-ID: 4a3f8b13.20...@yahoo.co.uk

I'm interested the relations of the boundaries for counties.  I notice 
that some counties (and recently English Regions) include the way for 
the coastline (natural=coastline), and some coastal counties do not. 

I think that coastal counties would benefit from a way to close the 
boundary, but does it make sense to use the coastline?  The coastline 
way probably indicates cliffs or a sea wall, yet there is often some 
beach or tidal flats beyond this on the seaward side.  I understand that 
councils are responsible for the beach so the county could be said to 
extend beyond what we currently mark as the coastline.  Does anyone know 
where council boundaries actually end with respect to the sea and 
coastline? 

Cheers, Chris


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


Re: [Talk-GB] maxspeed field - what units should we use. etc

2009-06-04 Per discussione Paul Jaggard
Hi

I think the principle of keeping it easy for the mapper should apply.  In
the UK, speeds are signed in mph, and most mappers will think in mph, so
let's record speeds in mph.  Anything else leads to confusion, conversions,
varying degrees of accuracy.  But to my mind, the worst result is the
inability to spot errors.

For example, a stretch of ring road near me has various speed limits at
various sections.  I could tell you it's 50mph for the first bit, 30mph at
the roundabout, then 70mph beyond.  But when I looked at it recently,
different bits were marked up with a whole jumble of numbers (including 112
on one side of the dual carriageway, 113 on the other).  Yes, I can convert
from km/h to mph and back again, but not in a quick glance.

When I map in France, I tag in km/h (just using a bare number), but in the
UK I absolutely want to tag in mph.

From a data consumer's point of view, it's not hard to take any fields with
mph at the end and preprocessing or converting on the fly, as long as
there's consistency in using an 'mph' suffix.  Seeing as there are more bare
numbers that are obviously km/h than mph, saying a bare number in the UK
should be interpreted as mph is asking for trouble, I think.

So, I think maxspeed=30mph or maxspeed=48 should both be acceptable and
equivalent, but maxspeed=30mph preferred in the UK.  maxspeed=30 should NOT
be used.

One word of caution when looking at the tag usage in the UK - I've had
swathes of my maxspeed tagging changed from mph to km/h by users (or their
bots) in Germany and elsewhere, so beware using the current usage list as a
measure how UK mappers want to tag.

Keep it simple for the mapper and tag what's on the signs, and use an mph
suffix to avoid confusion.

Paul
(southglos)
 
-Original Message-
Date: Thu, 4 Jun 2009 08:45:20 +0100
From: Peter Miller peter.mil...@itoworld.com
Subject: [Talk-GB] maxspeed field - what units should we use. etc

I have been looking at the coverage of maxspeed limit data for  
highways in the UK and we seem to have a right mix of styles.

Here is the data for bug chunk of England while avoiding including  
anything from France or Ireland (which would include km/hour figure).  
We current have over 17,000 highway ways tagged with maxspeed and also  
300 ways tagged as 'maxspeed:mph'. You will notice that for 30 miles  
per hour we have 30, 30mph, 30 mph, 48.2, 48.28,  48.280, 48.27808,  
48.28032 and 48.28.

Any suggestion on what we should recommend for the UK? I guess the USA  
should also be party to this discussion but they have far less  
population of the maxspeed field (only 70 uses in the Bay area) so  
possibly we should come to a view first.  Our options seem to be:-
maxspeed=30mph (the user should strip a trailing mph to find the value)
maxspeed=30   (leaving it for the user to realise that it is in the UK  
and therefore imperial)
maxspeed=30 mph (the user should strip the last word if it is mph  
including the space)
maxspeed:mph=30 (Easy for the user)
maxspeed=48.28 (with a defined precision) For metric use no work by  
the user, for imperial use a look-up table is required or a conversion  
and rounding



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


Re: [OSM-talk] immutable=yes Fwd: DEC Land

2009-03-09 Per discussione Paul Jaggard
Hi

Joining the conversation late here, but I assume this dataset is property
boundaries.  I can understand why you wouldn't want the boundaries
themselves moved, but what about the case where we want to build upon the
boundary data?  For example, a simple case might be: this bit of boundary is
a hedge.  I might then want to split a way that's part of the boundary
dataset, and mark a section of it barrier=hedge.  Doesn't sound that
unlikely, nor that unreasonable.

The fact that the boundary data would be in OSM would be valuable, but to
prevent anyone building upon it would undermine that usefulness.

Are we planning to import this dataset to give us raw data to build upon, or
is it just to store a copy of someone else's untouchable data, in which
case, what do we gain?

We don't claim any of the data in OSM is 100% correct, certainly we don't
claim that the OSM data is the definitive, legal definition of the world;
I'm assuming we won't be claiming to be the definitive source of the DEC
Lands dataset, nor feeding back into their dataset... so what's the worry?
Why should we be more worried about this dataset than, say, the exact
positioning of the road network?

Paul (southglos)


-Original Message-

Message: 6
Date: 9 Mar 2009 14:25:24 -0400
From: Russ Nelson r...@cloudmade.com
Subject: [OSM-talk] immutable=yes Fwd: DEC Lands
To: Talk Openstreetmap talk@openstreetmap.org
Message-ID: 7fb448f9-d4a5-4435-8922-1b0652b86...@cloudmade.com
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

Earlier, I proposed that certain datasets should be immutable; whether  
by policy or mechanism as needed.  I propose importing the NYS DEC  
Lands as an immutable set of data.  If you read this exchange with  
Robert Morrell, you can see why they feel that NO changes AT ALL are  
appropriate.  I agree with them.  This dataset constitutes a legal  
description of the property managed by the NYS Department of  
Environmental Conservation, and changes by any OSM editor are not  
consistent with the nature of the data.

How do people feel about me importing this data (with all of their  
metadata), adding an immutable=yes tag, with the intent of tracking  
their dataset, and deleting --outright-- any changes made by OSM  
editors.


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


[OSM-talk] FW: BBC 'Britain From Above'

2008-08-03 Per discussione Paul Jaggard
Interesting clip from the BBC:
http://news.bbc.co.uk/1/hi/technology/7539529.stm

It's a plug for a programme, 'Britain From Above', which starts 10th August,
but the trailer alone is worth watching for some lovely GPS-derived
visualisations.

Paul
(aka southglos)


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk


[Talk-GB] FW: BBC 'Britain From Above'

2008-08-03 Per discussione Paul Jaggard
Interesting clip from the BBC:
http://news.bbc.co.uk/1/hi/technology/7539529.stm

It's a plug for a programme, 'Britain From Above', which starts 10th August,
but the trailer alone is worth watching for some lovely GPS-derived
visualisations.

Paul
(aka southglos)


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-gb