Re: [Talk-transit] [Talk-GB] Mapping train services in Great Britain

[Mark Lester via Talk-transit]

This post is slightly spooky as only the other day I told Ed and Marc at 
opencage to reclaim the box, I can't be bothered anymore. It's been dormant for 
12 months. 
The bus stuff works certainly as poc. Getting hold of all the UK buses was 
beyond me, but Ireland and Holland have accessible saturation coverage of 
everything that moves. The process I developed handles both those countries on 
modest hardware within a day, RoI about 3 hours flat I think. I didn't pay the 
bill at digital ocean and they zapped my database despite the good money I 
paid.for backups. I was working at a planetary level if you like, I was piling 
on humongous amounts of data and repairing bottle necks. I had everything but 
North America, a substantial chunk but a lot less than half of the whole lot, 
and I'd already done the GTFS of countless other civilizations and bonkers 
datasets. Just from a fun point of view, New York is a scared place if you are 
building this. I was leaving her till last.
I looked at this subject very deeply for several years and produced a 
substantial architecture to handle not just national level , but the entire 
planetary infrastructure. To cope with that you are obviously going to need an 
incremental architecture, the data set is moving so rapidly you'd never get it 
printed. So I concocted an hierarchical incremental reductive tile rendering 
architecture I call Archimedes. So we not only print just what we need to but 
we can actually update the higher and global tiles in almost real time.Even 
places like Paris become a serious mouthful. We are trying to mechanically tag 
essentially our own way grouping with all the relevant services. The data is 
presented in an often super stupendously redundant manner I extensively stress 
tested this architecture. I was about to go coast to coast and hoover up all 
those Canoga Park metros in the US but I couldn't find the Greyhound stuff and 
hence not a national picture. It was intended as my gift to you, I do this for 
free. If the UK is so incompetent it can't even collect the GTFS that must 
necessarily exist for it to be on Google, Greyhound buses and Indian railways, 
consider the critical details of their national level public service to be not 
public domain information, and with nobody in here paying any commercial 
attention to me, I packed in. There are some potentially intractable issues 
with line/network reduction, I drifted off into trying to render a road map 
that would show me say Kazakhstan or Brazil at full view, but still handle 
Dortmund, Shanghai and the Eastern seaboard. I believe that is doable, and just 
the transport infrastructure is complex enough so needs btonbe addressed. . 
Just painting a substantial city in one view needs reduction and I wanted to 
build an interrogative map where you can pan out and discover stuff. We don't 
have much in the way of ferry data on GTFS but on examination of them on the 
map I decided they were quite reliable enough to be considered real. The boat 
network on the Irrawaddy delta is stupendous FYI.You can get away with 
scrawling the timetable on the map for ferries, it's perhaps a valid counter 
example as they are almost entirely mapped on a per service basis. The Baltic 
routes are too dense but almost everywhere else it's basically a service 
announcement. I guess that's accepted practice and I think it works. Doing it 
for bus and rail is futile and will result in worthless archeological data.
The only way this can be done is essentially getting the route planner to draw 
routes from GTFS. If you think that's not ultimately commercially feasible, at 
least not on a grand scale, we are just going to have to endure a world of bits 
and pieces where you have to in effect know where you are going beforehand, 
then in the final analysis I have to concede defeat. If on the other hand you'd 
like to have a go at an interactive bus map, and with a wee bit of cooperation 
from the route finding people also the trains, of the entire global published 
GTFS dataset, it is most certainly doable.







Sent from Yahoo Mail on Android 
 
  On Tue, 1 Jun 2021 at 4:58, Philip Barnes wrote:   On 
Mon, 2021-05-31 at 22:18 +0100, Michael Tsang wrote:
> On Monday, 31 May 2021 16:14:47 BST Roger Slevin wrote:
> > and one in which I agree with Tony, Mark and Peter in saying that
> > public
> > transport services and timetables don’t appear to me to have a
> > valid place
> > in OSM
> 
> We have already mapped the complete bus networks in certain cities.
> In OSM 
> terms, a public transport route is defined as "the order where the
> service 
> stops to carry passengers, and the path where it transverse on". It
> does not 
> include the timetable data.
> 
> I have also mapped a lot of bus and train routes in different cities
> as well, 
> and it is very useful for OSM to have bus and train routes. When I
> travel to a 
> new city I use OsmAnd a lot to find which bus I need to take to go to
> a certain 
> 

Re: [Talk-transit] Mapping train services in Great Britain

[Mark Lester via Talk-transit]

Wiring services directly into the map has obvious maintenance problems. Keeping 
the map aligned with timetable changes clearly isn't feasible. I don't believe 
this data belongs in the map proper.Using a route planner to calculate bus 
routes is feasible. I did a lot of work on this. It's all in JavaScript on 
Node. I can handle any public GTFS, you need to rationalize them extensively, 
they can be vast.Doing this for railways turns out to be much harder. You get 
trains doing crazy things at mega stations, you have to work out where the 
platforms are etc. It would be quite useful in the US where most of the network 
doesn't carry passenger services, or Argentina where there is an enormous 
network mapped which is largely derelict or just carries cattle.I was 
developing combined vector and raster tiles to support interactive network maps 
to any resolution. So you can zoom out and hover over the east coast mainline 
and get principal services highlighted. Or over a city and get to interrogate 
an otherwise impenetrable bus map. We have a transparent vector tile up to a 
limit laid over a full res raster. I gave up as I couldn't find anyone 
interested. The bus mapping was going very well, you just can't give this stuff 
away. The railways needs significant input from route planning guys to do this. 

Sent from Yahoo Mail on Android 
 
  On Mon, 31 May 2021 at 18:17, Tony Shield wrote:   
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit
  
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-GB] UK street addressing

[Lester Caine]

On 21/12/2020 11:14, Richard Fairhurst wrote:
More philosophically, post towns violate the “on the ground” principle. 
No one here writes their address as Chipping Norton unless PAF 
autocompletes it for them. No one has Chipping Norton on their 
letterhead. Trusting some remote third-party database in preference to 
local knowledge is not what OSM does, and particularly not OSM in the UK.


By all means namespace it (royal_mail:addr:city) or use a bespoke tag 
for what is a bespoke concept (addr:post_town). But let’s not remove 
useful information (the actual town/city) in favour of it, and let’s not 
tag as if post towns are an intrinsic part of UK addresses, because 
they’re not.


I have a similar problem with 'PAF autocomplete' ... my business address 
does not actually exist at all and the post code covers a large area of 
the business park, so even that is of little help to any delivery 
driver. Adding a phone number to the delivery details helps some of the 
time and with temporary drivers being used in the run up to Christmas 
I've had to talk a couple in this last week.


Full address is
L.S.Caine Electronic Service
Willersey Suite
De Montfort House
Enterprise Way
Vale Park
Evesham
WR11 1GS

The number of websites that do not allow for that in terms of numbers of 
lines or limiting lime length preventing two elements per line ... at 
least some of the delivery services are using OSM these days ... De 
Montfort House, Enterprise Way takes them straight to the door :)


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] UPRN wiki page

[Lester Caine]

On 18/11/2020 11:10, Robert Whittaker (OSM lists) wrote:

It's definitely possible for UPRNs to be assigned to streets. I think
you can tell this by searching for such a UPRN at
https://www.findmyaddress.co.uk/  (I don't look at that now since they
added a new T forbidding any use of the information for competing
purposes.) IIRC, that site will tell you if a UPRN you enter is a
street reference, and then refuse to provide the usual address
information.


It is worth pointing out that UPRN references identify parcels of land 
and in theory the whole of the United Kingdom is now covered by a 
continuous grid of land parcels with unique identifiers. Where a parcel 
is developed into multiple new smaller parcels then a new block of 
UPRN's will be generated by the local authority as defined by the 
planning documentation. So roads and amenity land which do not involve 
postal addresses will be defined along with other land registry parcels. 
I am not sure what happens with the original UPRN, but I would expect it 
to be tagged as 'ended' when the new contained parcels are 'started'. It 
should not be used as a part of the new batch for consistency but I 
can't find the 'rules' applied here. The new roads on the developments 
will then have new USRN references and Royal Mail will assign postcodes 
to these new roads. Many UPRN packets will never have a postal address 
listed in the PAF file ( and many businesses today are not properly 
listed either ) even if a postcode is used with that object as if it is.


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] Lorries can't limbo

[Lester Caine]

On 12/11/2020 23:54, Neil Matthews wrote:

And maybe network rail have a longer list / more info?


https://www.eveshamjournal.co.uk/news/18863187.lorry-blocking-badsey-road-getting-stuck/ 



Relevance for this the fact that the lorry has turned towards a disused 
railway line with a low bridge which prevented any recovery vehicle 
accessing from that end and any chance of pulling it out that way 
anyway. It had to be pulled back and exit the way it came in. Whether 
lorries of this size should even be on these roads is another matter :)


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] Solar tagging app

[Lester Caine]

On 04/10/2020 15:41, Russ Garrett wrote:

Once we have panel counts that multiple people have agreed on, I'll
batch insert the data into OSM using a new account - I will update
this list once that is happening.


I've just spent a couple of days working on Vale Park, Evesham and many 
of the units have panels on the roofs, so I think that is next on my 
list to do ... problem is I've not mapped these before, so what is my 
best starting point re adding them.


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] UPRN Locations Map

[Lester Caine]

On 26/09/2020 13:46, David Woolley wrote:
OS are in a funny position, in that they are in the public sector, but 
are expected to be self funding.  To the extent that they succeed in the 
latter, they don't owe a duty to the taxpayer.


But since the vast majority of the UPRN data is actually collected and 
managed by the relevant councils, the question is do they have the right 
to restrict access when it is council taxes that pay for the management 
of that data and not OS! SHOULD we perhaps be asking the various 
councils for direct access to the raw data under the open data umbrella?


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] How closely do we map lamp posts?

[Lester Caine]

On 02/09/2020 19:00, Dave F via Talk-GB wrote:
I don't know the area. but they look like the existing posts to me. Has 
the cycle path been realigned around them to provide better vision 
splays/ stopping room to motorists?


https://www.google.co.uk/maps/@51.7730673,-1.2396435,3a,56.4y,188.18h,85.12t/data=!3m6!1e1!3m4!1sCSZk4LPVkVJecufviv4kzw!2e0!7i13312!8i6656 

I believe it's something to do with building regs. Existing posts have 
to be one of the last items to be decommissioned, usually by newly 
installed ones. Similar happened on one of the London CS ways, where 
everyone got their knickers in a twist over it.


The fact that a neatly finished cycleway surface now has to be dug up so 
that the electric supply can be moved to a new location and the lamp 
pole moved is just another example of the complete waste of money many 
of these 'improvements' result in? Actually another question is just why 
the kerb to the footpath and the cycleway had to be moved at all? It no 
longer lines up with the next section anyway.


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

[Talk-GB] How closely do we map lamp posts?

[Lester Caine]

https://www.bbc.co.uk/news/uk-england-oxfordshire-53999106
One does wonder about the competence of builders at times?

--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] Street-name toids

[Lester Caine]

On 13/08/2020 10:55, SK53 wrote:
That was me too, I would have added the USRN if I'd had it immediately 
accessible. My understanding is that UPRNs do apply to roads, but have 
much to learn about them. I've added them to a couple of others at 
Cinderhill which is housing built on open fields so no historical 
properties there.


This is a case of establishing what the UPRN actually relates to in 
terms of the parcel of land covered by it. There WILL be a UPRN for 
either the parcel of land, or even for the individual fields, but those 
will be superseded by the new UPRN's for each of the subdivided parcels 
in the new development. It is MY take on things that publically adopted 
roads only have a USRN and the historic UPRN is simply that - an 
historic record. But I believe ( and stand to be corrected ) that 
private roads do require a UPRN covering the ownership of the land? The 
UPRN is in essence the reference to the land registration showing 
ownership, and it may be today that councils are registering the 
publically adopted roads as has been seen recently with their claiming 
ownership of land people thought was part of their gardens but which the 
council want to sell them ... even where land registry records show a 
different situation?


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

[Lester Caine]

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

Aug 9, 2020, 10:25 by pang...@riseup.net <mailto:pang...@riseup.net>:

I suggest we create a roadmap for deprecating of storing and
updating names in OSM for objects with a Wikidata tag.

Absolutely no.

tagging name tag is a fundamental  part of OSM tag,
offloading it to a third party service is a mistake that will not happen

https://josm.openstreetmap.de/ticket/19655 contains several misleading, 
wrong, mistaken
and problematic claims, statements and implications but I have no time 
to process in detail
as the entire idea is fundamentally bad, mistaken, problematic, broken, 
not workable,

not acceptable, not going to happen and wrong.


Seconded ...
However sensible LINKING to third party services does make sense such as 
with geonames which already has services linking back to OSM ... 
geonames is a useful source of local time data for example.


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] UPRN tag proposal page

[Lester Caine]

On 21/07/2020 12:42, Nick wrote:

Hi Lester

Rob has suggested a matching USRN tag

You make a good point regarding upper and lower case. Perhaps the tag 
should be ref:GB:UPRN in line with normal convention of referring to 
UPRN in upper case?


I was only thinking about the country code as I've seen both cases used 
on a number of different countries and I'm used to 'tags are lower 
case', but in reality these days, USRN and UPRN are the correct case as 
is GB so yes - if there is no rule on tags being lower case - then 
ref:GB:UPRN IS the correct format!



Nick

On 21/07/2020 10:34, Lester Caine wrote:

On 20/07/2020 22:11, Rob Nickerson wrote:

If there are no red flags I will move for a vote.

Looks sensible to me but will there be a matching usrn tag?

I see the occasional use of :gb: on other tags and any 'convention' on 
upper or lower case is possibly an international one, but I'm not sure 
anything actually says the country code being upper case trumps the 
convention of tags being lower case? I'm a long time PHP user where 
the case is agnostic anyway in many cases but again that is not 
specified here either ...

--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] UPRN tag proposal page

[Lester Caine]

On 20/07/2020 22:11, Rob Nickerson wrote:

If there are no red flags I will move for a vote.

Looks sensible to me but will there be a matching usrn tag?

I see the occasional use of :gb: on other tags and any 'convention' on 
upper or lower case is possibly an international one, but I'm not sure 
anything actually says the country code being upper case trumps the 
convention of tags being lower case? I'm a long time PHP user where the 
case is agnostic anyway in many cases but again that is not specified 
here either ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] The curious case of USRN 20602512

[Lester Caine]

On 10/07/2020 22:27, Nick wrote:

Hi Lester

I think there needs to be some thought as to the "proper channel to feed 
corrections to the 'data officer' responsible". It took me months to get 
a 'data officer' to correct the location of a single UPRN, so my thought 
is that this needs to be a 'public' (open) channel that shows a) the 
number of issues identified (the rationale for making data open) and b) 
how long it takes for these to be investigated and resolved (if 
appropriate).


TOTALLY AGREE ... local authorities MAY be required by law to provide 
the data, but they get no funding, and no support to manage that data 
yet third parties have been making money from it! SO the next step is to 
document all the mistakes. There should be no assumption that the 
current data set IS correct, which is why it should be used as a 
parallel layer and not simply imported over what may well be more 
accurate data.



On 10/07/2020 14:21, Lester Caine wrote:

On 10/07/2020 11:27, Mark Goodge wrote:
This is, of course, one of the problems with proprietary data. It can 
be difficult to spot errors, because the people who are most likely 
to spot errors - members of the general public with local knowledge - 
tend not to have easy access to the data.


Spot on ...
The 'proprietary data' is however the input from the relevant officer 
at the council covering the area. Probably originally tacked on to 
another job description and someone who probably had no training is 
this 'new' function? I was receiving NLPG updates for many years and 
the vast majority of 'updates' were corrections to data rather than 
additions. The problem has always been not allowing public access to 
what has always been public data and now we do have access there needs 
to be a proper channel to feed corrections to the 'data officer' 
responsible for the relevant slice of raw data. I don't think THAT has 
changed since the requirements for councils to provided the raw NPLG 
data passed into law? I'm fairly sure the street data is part of the 
same legal framework ...




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



--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] The curious case of USRN 20602512

[Lester Caine]

On 10/07/2020 11:27, Mark Goodge wrote:
This is, of course, one of the problems with proprietary data. It can be 
difficult to spot errors, because the people who are most likely to spot 
errors - members of the general public with local knowledge - tend not 
to have easy access to the data.


Spot on ...
The 'proprietary data' is however the input from the relevant officer at 
the council covering the area. Probably originally tacked on to another 
job description and someone who probably had no training is this 'new' 
function? I was receiving NLPG updates for many years and the vast 
majority of 'updates' were corrections to data rather than additions. 
The problem has always been not allowing public access to what has 
always been public data and now we do have access there needs to be a 
proper channel to feed corrections to the 'data officer' responsible for 
the relevant slice of raw data. I don't think THAT has changed since the 
requirements for councils to provided the raw NPLG data passed into law? 
I'm fairly sure the street data is part of the same legal framework ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] UPRN Locations Map

[Lester Caine]

On 04/07/2020 23:14, Cj Malone wrote:

On Sat, 2020-07-04 at 22:24 +0100, Lester Caine wrote:

What is needed is a means of adding LAYERS of data which can be
managed either via third party data sets, or manual edited using
existing tools to add data that is missing from the narrow view
confined to 'current' objects ...


If I understand you right, I like the idea of this, for example a layer
of bus stops in the UK would be sourced from NapTAN. That layer would
be kept up to date with NapTAN (most bus stops in OSM are a decade old,
unmodified, not validated) and OSM mappers could add
corrections/modifications.
Potentially we could have a line of communication to NapTAN to inform
them of errors in there dataset.

It'll be hard to change some peoples minds, but it's worth discussing.


That is one example and if editing the data can be carried out using 
existing tools then new data sets can be created in a similar way. My 
own tools for handling NLPG data was targeted to allow councils to 
automatically create update data sets as they create new uprn's or 
correct existing ones.


But my own interest is not so much the independent layers like NapTAN 
but being able to update current records with historic details such as 
start_dates which apply to CURRENT objects, but also maintain data that 
has expired due to end_date.


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] UPRN Locations Map

[Lester Caine]

On 04/07/2020 20:33, David Woolley wrote:

On 04/07/2020 18:24, Lester Caine wrote:
The current 'OHM' is not a layer that can be easily combined with the 
current 'OSM' layer. Large sections of the current data are simply 
cloned into OHM


I'm not referring to OHM; I'm referring to the main OSM map.  At least 
since September 2012, OSM has the complete back history, and, as far as 
I can see, you can use overpass API to retrieve the map as of any date 
and time since then.


BUT you can't upgrade the data in that history, only access previous 
data without any reference to if it is correct or not. OHM is not a 
solution to add the missing history, or correcting that history which 
was removed because of mistakes. It is simply a record of what was done 
with all it's mistakes ...


What is needed is a means of adding LAYERS of data which can be managed 
either via third party data sets, or manual edited using existing tools 
to add data that is missing from the narrow view confined to 'current' 
objects ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] UPRN Locations Map

[Lester Caine]

On 04/07/2020 12:54, David Woolley wrote:
At the very least data currently live in on a 'current' view should be 
automatically filed to an historic layer when it is replaced


How does this differ from how OSM already works?  You can already create 
versions of the map at any point in its history, except where data has 
been redacted for legal reasons.


The current 'OHM' is not a layer that can be easily combined with the 
current 'OSM' layer. Large sections of the current data are simply 
cloned into OHM anyway. Providing an historic layer which only holds the 
data that has changed over time AND using the same tools to expand on 
that historic data as are used to map current data removes another 
hurdle to maintenance. If third party data such as NLPG can be processed 
to provide it's data as another layer which can then be combined in the 
one view then it removes the need to simply import large data sets. One 
simply uses which set of layers you want ...


Of cause the other approach is simply merge all available data ... past, 
present and future ... into the one humungus database and navigate the 
problems of maintaining potentially thousands of data sets in sync with 
the 'master' copy.


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] UPRN Locations Map

[Lester Caine]

On 04/07/2020 08:51, Stephen Colebourne wrote:
I'm not convinced this data should be pulled into OSM. It would add a 
lot of clutter that users would be tempted to move around or delete. In 
areas like mine where I've added thousands of buildings and addresses 
from surveys, it would be making matters worse not better. It would be a 
disincentive to adding more buildings with addresses as the additional 
nodes would get in the way of editing, and because they represent a semi 
random set of things. Because the dataset is fixed I would think it 
should be a layer used alongside OSM by those tools that think it adds 
value. Ideally, OSM itself should support layers, but AFAIK it doesn't.


That about sums it up. The plans themselves may be a starting point 
where there is nothing, but ALL that needs importing are the references 
being added to existing objects in OSM. As you say, the data in the NLPG 
data set is 'read only' and so anybody 'editing mistakes' may not 
understand that it is displaying what is the 'legal' situation on the 
ground. Any mistakes need to be reported to the right authority.


That OSM does not support layers is now a major stumbling block. At the 
very least data currently live in on a 'current' view should be 
automatically filed to an historic layer when it is replaced, but with 
the growing volume of other data sources with detailed graphical 
content, being able to combine layers of data should be a high priority. 
There should then be no need to import snapshots of those managed data 
sets and have to maintain mechanisms to keep the two in sync. Just use 
the raw data direct in parallel with the unique OSM data.


It is worth pointing out that unless something has changed drastically 
in the last few years, then the range of fine detail contained in the 
NLPG varies vastly between the various council sources. I think I have 
seen comments about 'only having a node' and not providing enough detail 
to identify different references. Certainly 10 years ago only a small 
number of councils actually had plans of the extent of each council tax 
parcel and other fine detail. Most just had a node somewhere in the 
right area. Many were reliant on paid services from OS for map data and 
so did not have a licence to copy that data over. HOPEFULLY today that 
particular problem has been resolved.


I've not had time yet to look at just what is available against the now 
somewhat out of data local extracts I have from the original NLPG dataset.


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access

[Lester Caine]

On 24/05/2020 23:45, Mateusz Konieczny via talk wrote:

There are also many roads signed as "No HGVs except for access." It
is tempting to tag them as "hgv=destination" but that doesn't cover
the case where you are allowed to follow that route for many miles
and make several turnoffs IF you "need access". The current
definition of "access=destination" doesn't allow routers to
distinguish between truly "first/last segment only" and "its fine if
you are going to/from this general area".

AFAIK this awaits solution, at least I am not aware about even a tag 
proposal.


A delivery driver following a drop list may have a drop on that road, 
and then go on to their next drop out of the other end of the road. In 
fact it may be that the road is impractical for the vehicle to turn 
around. The 'legal' restriction is to prevent lorries using it as a 
short cut through a residential or similar area and physically it is 
perfectly practical for the biggest legal vehicle. The router can simple 
avoid that road if there is no stop on it, but the tagging should 
ADDITIONALLY indicate if it is physically possible to get the vehicle to 
the destination so obstructions such as tight corner, overhanging 
buildings, weight restrictions and the like will prevent some of the 
examples of lorries blindly following their sat nav without their brains 
in gear? It is the routers problem to pick the best route, which may be 
to approach the destination from the other end and perhaps even indicate 
'back up to destination' ... now that WOULD be an intelligent router ... 
but if there is no information on which to base that decision even the 
driver has to guess.


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [OSM-talk] our Q site help.openstreetmap.org is dying

[Lester Caine]

On 20/05/2020 20:32, Frederik Ramm wrote:

Not copying past answers, at least the last two years or so, would mean
we'd have to write all these answers again because the questions will
inevitably be asked.


I'm with you on that ... I've seen far too much material simply ditched 
because it been to difficult to 'recover' it after systems stopped working.


So where would I head to get my hands on an XML dump of the current data 
to see if I can push it into the copy of Q2A I've just set up ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [OSM-talk] our Q site help.openstreetmap.org is dying

[Lester Caine]

On 20/05/2020 08:28, Tobias Wrede wrote:


The site is based on OSQA, a software which has not been maintained in 
some time. Some application errors have surface in the past but had to 
be ignored since no fixes are coming from OSQA any more. Until now we 
could live with that. They were annoying but not critical. There are 
open tickets on OSM github to move the help site to some other framework 
(https://github.com/openstreetmap/operations/issues/149, 
https://github.com/openstreetmap/operations/issues/377) but there isn't 
exactly an abundance of volunteers to take care of that.


Question2Answer looks like it's being well supported. At least it has a 
release that works on the latest PHP and while it's a little long in the 
tooth, https://github.com/jamesspittal/osqa-q2a offers a hope that there 
is potential to pump existing material across?


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence

[Lester Caine]

On 10/04/2020 17:37, Brian Prangle wrote:

Can I ask two  basic daft questions?

Perfectly reasonable questions ...

What use are these in OSM if we only pick at them instead of importing 
the lot ( which is  highly unlikely)?
I'll repeat that we do need to wait and see exactly what will be 
released, and how comprehensive the data is, but in theory it should be 
quite possible to cross check a vast range of 'objects' in the database, 
and more important pick up additions and subtractions of those objects 
automatically. The comparison is probably with the French property 
database which I understand has been imported, but I would still prefer 
to be able to merge third party sources like this with the existing 
outline in OSM rather than simply importing everything into OSM ...


Is it possible to derive street names from USRN in a way that is licence 
compatible?
Exactly the same answer as above, but we know exactly what objects are 
being handled, and if populated, the exact status of a 'way' can be 
confirmed. The accuracy is only that of the data sources, but there is a 
legal requirement for councils to provide updates in timely manor. My 
feed was 3 monthly, but I think faster updates are now happening at 
least as new road names are created.


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence

[Lester Caine]

On 10/04/2020 08:04, Jez Nicholson wrote:
I don't think they meant 'replace an address with addr:uprn', just 
enhance it.


I was not being as clear as I should have been. A UPRN parcel of land or 
object includes those for which an address is not appropriate and which 
'Royal Mail' would never deliver to so I don't think it is appropriate 
to merge with the addr: set. I've already indicated that we need to wait 
and see just what quality of data will be provided, but I ecpevt that 
some council areas will not actually have postcode in the data. 
Certainly 15 years ago when I started receiving datasets this was a 
secondary piece of data yet at that time we were looking to manage the 
postcode tables for the councils that were providing the UPRN feed! They 
were not prepared to pay Royal Mail for data that they were legally 
required to create themselves ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence

[Lester Caine]

On 09/04/2020 20:58, nd...@redhazel.co.uk wrote:

If uprn is supposed to denote an address, why not simply use addr:uprn?
There is no intention that UPRN will replace an address. It will be able 
to return a unique address but there will be no move to remove that 
duplicate data from OSM. What the UPRN allows is the addition of 
external information which is also managed by public services.


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence

[Lester Caine]

On 09/04/2020 15:32, Mark Goodge wrote:

So I'd propose that we use either ref:uprn and ref:usrn, or
ref:UK:uprn and ref:UK:usrn. What does everyone else think?


I'd be happy with either, so long as it's consistent.


That is ideal from my point of view ... yes you can get the country by 
processing the location information, but being able to simply list all 
of them WITHOUT the overhead of other processing has to be the right way 
forward?


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence

[Lester Caine]

On 09/04/2020 10:46, Peter Neale via Talk-GB wrote:

Hi Lester,

Sorry if my post was a bit of a rant.  I have a history of having to 
fight to get IT systems that do the hard work and preventing them 
demanding that people do the translation into "machine-speak".
My rant has always been that postcodes are proprietary data and even in 
the NLPG data there is a question on if one can use it! The whole thing 
has always been a mess. Postal Address File I have no problem on being 
proprietary, just not the postcode on it's own ...



Thanks for the explanation.


I've had to change most of the references but
https://rainbowdigitalmedia.uk/wiki/view/NLPG+Data
is now up to date, just again, BS7666 is another chargeable element and 
my copy is no longer available on-line :(


OH and it should be UPRN/USRN nowadays ... my 2006 databases still have 
the USN field name.


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence

[Lester Caine]

On 03/04/2020 10:15, Peter Neale via Talk-GB wrote:
So, will I have to quote a 20-digit alpha-numeric code, if I want to 
order something from Amazon? ..or get my grandchildren to send me a 
birthday card?


(I do not know what these UPRN's look like, but I bet they are not as 
easy to remember as "Rose Cottage, 3 Church Lane, XX3 4ZZ")


We have to think about human readability and memorability, versus 
machine computability and we need to be careful not to make the humans 
do all the work, just to make it easier for the machines.  Making me use 
a PostCode is already making me do some of the work, but at least they 
are only 6 or 7 characters.


The NLPG is intended to provide a single database of all the land in the 
United Kingdom. Councils have been building this for many years now, and 
it allows parcels of land that the Post Office do not have any reference 
to in their Postal Address File to be uniquely identified. Looking up 
data using Postcodes can be fun but often due to people having the wrong 
postcode anyway. We can identify the vast majority of residential and 
business locations using 'building Number'/'Postcode', but additional 
data is useful to identify that this short form is actually correct, but 
your council tax or business rates will be charged against the UPRN 
reference on the council systems. It is not intended to be anything 
other than a 'machine readable' unique refference ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence

[Lester Caine]

On 09/04/2020 09:19, Tony OSM wrote:

Thanks to Andy for highlighting this.

If the data is to be in the public domain the next step has to be tagging.
As someone who has been using this data internally for clients who are 
the councils who have been providing it TO the charged for services I'm 
pleased that now I will not have to worry about linking that data to OSM 
data.



Do we need country specific tags for these two pieces of data?

https://wiki.openstreetmap.org/wiki/Key:ref:NPLG:UPRN:1
has existed for a while, but the matching Key:ref:NPLG:UPSN:1 doesn't as 
yet. Personally I think this style is messy and a GB/UK element would 
make sense ... and actually identifying that this is United Kingdom 
related in the wiki page would be helpful!



What should they be?

Do we need a wiki for them , where?  I'll summarise the answers and 
create a wiki page if someone tells me where to place it - a UK specific 
page or section?


Any traction in creating tools to help populating any new tags?
It will be nice to see just what level if data is provided on the public 
feed when it becomes available. The level and accuracy of the data IS 
very much dependent on the level of effort that each council puts in, 
with some providing the full details of the land area described while 
others only provide a location reference. So there will be some problems 
producing a 'generic' tool to add UPRN tags to buildings and land plots. 
USN references should be a lot easier to automatically merge since the 
street name provided via OS data sets is the same one as used in USPN 
... or should be ...



Could this be a subject for a discussion as the probably virtual OSM AGM?


This is just a United Kingdom discussion currently although as I 
understand it a few other countries do have something similar so a 
common country based tag for 'Property Reference' and 'Street Reference' 
may be a valid subject. But UPRN and USN seem right anyway.


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] Adding missing roads using Facebook detections

[Lester Caine]

On 27/03/2020 13:04, Brian Prangle wrote:
I echo Richard's comments - best to confine yourselves to new roads in 
recently constructed residential developments - and even here you need 
to be careful  as on the ground some roads will be service roads and 
some will  be living streets and there will also be gated communities 
(can you detect gates?). So definitely do not add access tags as these 
require a ground survey.


I would also add that having been FIGHTING the Facebook Places naming 
process, I do not conciser Facebook as anything like a reliable source 
of data. I've along with others have given up trying to get the correct 
CURRENT place names properly referenced and in recent years even when we 
had got links fixed they have now been rolled back to long out of date 
references. See the UK Places list on facebook ... 
https://www.facebook.com/groups/ukplaceseditors/ ... for examples of the 
problem, although the wiki site which carried all of the reported errors 
has now been taken down by Facebook :(


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

[Talk-transit] BuzMap update

[Mark Lester via Talk-transit]

Hello Mappers,  I have been back on my project since the start of February and 
wanted to give you an update. Actually I needed to in order that I could draw 
some kind of line and get back to the main task in hand. I have seriously fixed 
my merging code, at least enough to handle the transit network and to inherit 
accurately. Trying to render the entire planetary transport network, including 
all roads, on a single tile, is perhaps pushing it a bit. So I will take my new 
publication system, chuck away a huge chunk of needless code currently in use 
for the buses+trains, and get you a working point sand shoot from any altitude 
bus map.  It's about time we made a blog, so here is my post, I saved any other 
historical free thoughts in there too. I hope to have some actual progress on 
the bus map itself, with or without this attempt at high level global road 
views, by then end of April. Stay safe, stay in, and code. The Quest for the 
"Earth Tile"



| 
| 
| 
|  |  |

 |

 |
| 
|  | 
The Quest for the "Earth Tile"

I have returned to the project and have spent the last 7 weeks rewriting the 
publication and simplification code...
 |

 |

 |



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

Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[Lester Caine]

On 25/02/2020 23:39, Alan Mackie wrote:
Vector tiles that prefer either the browser's requested languages or 
something selectable would be ideal, but we aren't there yet technically 
for the main 'editors map'. When we are it might be worthwhile 
revisiting this discussion.


There are complaints about what language to use everywhere. Even such a 
fundamental part of the infrastructure as 'timezones' has an ongoing 
debate about just how to spell the ENGLISH name of some identifiers and 
there has been a growing push to simply drop the 'names' and use 
abstract references so close the discussion once and for all. The 
argument here HAS been a problem since day one, and I remember 
discussions on converting tagging to use ID numbers rather than names 
... what ever language they are written in. Just as with timezone 
identifiers, many of the text strings used can be 'translated' into any 
language one likes to DISPLAY them, and what has always been missing is 
a part of the API that simply allows one to select the language one 
would like to see ... and something which vector tiles could easily 
support ... but just as browsers still have problems with the simple 
stuff like returning a clients ACTUAL timezone (time offset as ALWAYS 
been the wrong information), the basic simple steps have never been 
defined in any standard?


That the current 'map' is missing names for many graphic objects is just 
a matter of who controls the style sheets. Personally I prefer the 
French tile sets over the main version and have to accept that road 
colours are wrong. None of that affects the flexibility that the raw 
data provides, although a nice 'United Kingdom' colour set on OSMAND is 
still on my own todo list, and the vector maps THAT produces have 
potential to solve many of the 'complaints' ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

[OSM-talk] BuzMap - Global Transit Map http://buz-map.com

[Mark Lester via talk]

Hello Mappers,I've been building this http://buz-map.com, there's a couple of 
read me's at the top. There are a stack of issues but this now looks eminently 
doable.
My pitch on all this is that people like maps. Give people a map of a transport 
network and they will follow the wiggly lines. They will notice that an island 
has a connecting ferry and a bus network (see Estonia). Envisage mountainous 
and wilderness areas and their transit geography more easily (see Sweden). Be 
able to scan an entire metropolis network to it's extremities without having to 
use trial and error (see Paris, Prague, Petersburg, Athens). And generally be 
intrigued and want to zoom in and discover. I am not having much success 
evangelizing this view with regard to a global transit map. If I can get this 
to a production state with all known GTFS, and sex up the high level areas that 
have no listed transport with a much deeper road network than you normally get 
at higher tiers, we will at least have the "intrigue me" travel map that I 
personally want. Obviously I haven't got very far with the front end. In 
particular it's not interacting very well on mobile, it's lousy in fact. I need 
help in any way shape or form available but if anyone knows how to get a thin 
line to interact in Leaflet on mobile, please suggest. I did try to paint a 
massive invisible one on top but it didn't work and I got nowhere with the 
debugger, so even help with that would be appreciated. I also want to do funky 
stuff like flipping the railways or buses to the foreground on touching. In a 
dense centre of a metropolis, being able to flip the metro or tram network to 
the top is already an important requirement. The Mapbox stuff does this but I 
haven't sussed the layers within tiles stuff and how to do it yet.
I've got a game plan to fix most of the other bugs, especially in the rail 
routing which is quite screwed right now once you zoom in. I will get the whole 
of the visible GTFS world on there, so all of USA that's available, and 
anything else that I can find. It's going to take a few months, probably most 
of the year including downtime. I say visible GTFS, as oppose to existing. 
There is an awful lot of bus data that patently exists as it's in booking 
engines, and in GTFS form if it's on Google, but isn't anywhere easily found.
What I want to investigate is to use the reduction method I have to draw 
efficient level 8 to 1 vector tiles of simplified road networks. So you can 
look at say all of India, US, Canada, China, Russia, Brazil or any area of that 
size, and get a decent view of the national road infrastructure even if I 
haven't got any bus data yet. I still will need to do some of the same simple 
reduction used for doing the detailed lower tier standard rendering of levels 
7-16, i.e. filter road classifications down once it becomes an unavoidable mess 
even with reduction, leaving only motorways for the top two or so tiers. I 
think we will get a usable, readable and "representative" map of these upper 
layers, which by default are either road light or completely vacant. The bus 
network I have in Europe, which is just a tiny subset, is messy at the high 
level, I will try to refine it, but the trains work, so I am sure motorways 
will too and we'll tune in the lower road classifications and with appropriate 
clustering radii as we proceed down the tile tree.
Any input gratefully received. Apologies for the spam of three lists, please 
respond directly unless it's something of interest to more than just me. Also I 
am in contact with OSM folks, I know I am using free tile servers. How we run 
this as a public self funding service is one of the many things I need help 
with. It seems an obvious gimme for anyone selling bus tickets but it's not 
easy to get anyone to pick the phone up. I have resigned myself to having to 
build a production system in between doing not a lot.

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

Re: [Talk-GB] Ground truth v legal truth

[Lester Caine]

On 19/07/2019 16:04, Philip Barnes wrote:

As the sabristi have already discovered this one, and the OSM edits
appear linked to Sabre Wiki edits, I will identify it.

In this case I am concentrating on A5191 (Coleham Head, Belle Vue Road,
Hereford Road)https://www.openstreetmap.org/#map=18/52.70122/-2.74811

Not a primary on the ground as can be seen on mapillary.


https://www.sabre-roads.org.uk/wiki/index.php?title=A5191
As some say, sabre is not an official source but it does use OSM as it's 
mapping tool!


Essentially this seems like the opposite of my own problem. Around here 
the A46 moved over closer to Evesham, and the old road became the B4632. 
Traffic is then pushed towards the A46 and what can be a 10 mile+ detour 
over the other more direct routes linked with the B4632 and even the 
secondary B4632 is 'avoided' by the routers! In your case the preferred 
route would seem to be the A49 and rather than downgrading the old route 
to a B road it's been left with an A designation? Bottom line is if the 
A5191 is used on traffic reports it should be identified. That it is not 
now a 'preferred route' is a problem, which in practice was screwed up 
by giving it the A5191 designation in the first place, and tagging it 
'tertiary' IS breaking the rule don't tag for the router :( In the 
absence of something to override the 'primary' rule set then we are a 
bit stuck, but that should be something additional to what is the 
documented designation. That the road classifications provide a crude 
rule set for routing has always been a problem but in the case of the 
A5191 what is the speed limit? I think I would expect 30MPH if it is 
essentially 'residential' which should push routing to faster 
alternatives, but we are now seeing 20MPH zones even on primary roads to 
calm traffic and provide direct rules for routing?


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] Automated Code-Point Open postcode editing (simple cases only)

[Lester Caine]

On 19/07/2019 15:15, Andrzej wrote:

Do others agree with it or would you rather have more postcodes in database 
first and work on accuracy and completeness afterwards?


Andrez ... while the code-point table does provide a list against which 
missing post codes can be identified, the key piece of information that 
is needed is to add a road name to the post code, and that is not 
something that is easy to establish currently.


If we all simply add address data to places we visit the gaps would fill 
up quite quickly but I'm guilty of not doing that. I've a list of 
postcode I have been looking up on OASAnd and not finding which I need 
to actually put in!


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] Ground truth v legal truth

[Lester Caine]

On 19/07/2019 15:14, David Woolley wrote:
The logical consequence of ignoring the official classification if it is 
not signposted, is that you cannot map tertiary, because with, very rare 
exceptions, they are not signposted and you can only distinguish them 
from residential by using the official sources, or by personal judgements.


Certainly the key tertiary roads around this area ARE easy to identify 
on the ground and while small sections could be tagged residential or 
service the majority of the roads are clear 60MPH routes in open 
countryside and are essential 'primary' routes to get from A to B 
without long diversions through M,A & B roads many of which have a 40MPH 
speed limit! As I said ... this is not a case of tagging for the 
routers, but simply identifying the facts on the ground which often are 
clear. These roads to not have primary route reference numbers ... but 
they are a key part of vehicle routing.


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] Ground truth v legal truth

[Lester Caine]

On 19/07/2019 13:37, Tom Hughes wrote:

On 19/07/2019 12:55, David Woolley wrote:

On 19/07/2019 12:36, Philip Barnes wrote:

I cannot dispute this is legally a primary, OS Opendata shows it.


I would say the logical consequence of that argument is that no road 
should be mapped as tertiary, as, unless taken from OS, it is a 
subjective judgement and can't be consistently verified.


That doesn't follow - in the UK we have always (with very rare
exceptions like Oxford High Street) mapped secondary, primary and
trunk to the official status of the road.

Roads with no official status as A or B roads are then divided
between tertiary, unclassified and residential on a more subjective
basis.


Agreed ... if a UK road has an official reference it's classified. If 
not then it's tertiary if it does form part of the main road system and 
unclassified if it's not suitable for normal vehicle use. MANY of the 
roads around here are 'class c' and while it IS tempting to re-tag them 
as a higher level in order to get the routers to actually work, it's the 
routers treating them as lower speed routes which is the problem. At 
least around here and that is when 'service' as opposed to 'tertiary' 
should apply where a route IS more access route than primary link 
between to 'higher classification' routes.


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [OSM-talk] handling street names in speech

[Lester Caine]

On 17/07/2019 08:29, Jo wrote:
Unfortunately TTS is not perfect and it never will be, for one thing 
because it's often difficult to decide with TTS (which language) to use 
for each word in a name string.


For many years I used a TTS engine called Rhetorical on a caller 
management system we supplied. It was used to allow calling people by 
name rather than ticket number ... we will ignore the privacy debate ... 
there was a general consensus that at that time the personal style was 
better. The nice thing about Rhetorical was that even without any help 
it did a better job pronouncing foreign surnames and some of the staff 
did ;) It also had a very good mechanism for adding improvements to 
words when there was any particularly obvious mispronunciation. In 
addition selection of a different 'output language' worked well, 
possibly because the company involved was based in Scotland, and the 
clarity of Scottish pronunciation worked well. We had already had to 
re-work the older 'English' segmented announcements using a Scottish 
voice because of complaints ... but perhaps the main point here is that 
this was providing THE SAME English text!


Rhetorical was bought up by an American company and essentially dropped, 
but I think CereProc is using the same engine and a large range of 
'voices' are available on Android ... if only OSMAnd could access them :(


Text to Speech rendering is exactly the same problem as tile rendering 
and adding tagging for particular processes will always be wrong. The 
real problem is that there is no mechanism to add corrections in a 
secondary system in much the same way as there is no translation system 
for the key English elements of the data. Even IPA strings depend on the 
context and accent that is being vocalised!


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [OSM-talk] Ways divided by paint?

[Lester Caine]

On 04/07/2019 15:24, Mike N wrote:
What if strictly following the rule of "no split ways unless physical 
divider" results in wildly incorrect turn-by-turn instructions?


I have the same problem with the right turn lane being removed from 
https://www.openstreetmap.org/#map=19/52.11366/-1.94141 ... one can 
transition from the A46 to the A44 heading north WITHOUT having to stop 
for the roundabout. Because the only separation IS a crosshatch area the 
slip road has been removed but there is NOTHING to indicate that this 
slip road even exists by any other tagging! Unless someone has an 
'approved' way of adding it back?


Personally I think that micro-mapping complex junctions does require 
multiple ways even if the planned routes through a junction can be 
abused by taking the wrong path ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] Is metric or imperial units system used for max weight signs in UK?

[Lester Caine]

On 20/06/2019 16:49, Mateusz Konieczny wrote:

According to information that I found UK switched to metric system,
at least as far as max weight signs go - with exception of Guernsey that 
use hundredweight

as a unit.

Is this correct? Are there still traffic signs using pounds as an unit?


I'm fairly sure that weight limit signs are always in tonnes and have a 
't' after the weight figure. The regulations certainly refer to 7.5 
tonnes as a base for weight restriction for structural reasons and 
vehicle plated limits are in tonnes.


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [OSM-talk] Documenting controversial iD decisions

[Lester]

On 29/05/2019 01:10, Clifford Snow wrote:
Why should one editor be held to higher standards than others? Shouldn't 
they all be held to the same standard?


As someone who still fights to keep potlatch2 working locally then yes 
all options should be judged to the same standard, and there are 
defaults on all editors that simply don't work or contradict what 
another editor 'defaults' to providing. Invariably I end up on 
'advanced' so I can override choices given even in potlatch2.


The 'standard' should be the current tagging guidelines and NOTHING 
should prevent an editor from adding changes that ARE still evolving. 
lifeguard facilities are a good example of the sort of additional detail 
that is still developing. So being able to add that detail is important 
even if it needs manual assistance. NO editor should enforce it's own 
restricted view of tagging here.


I'm still of the opinion that what I will call 'primary' keys should be 
more regulated, and that the API provides the standard for key elements 
like highway and building. highway=platform is a key element of my view 
of the data and simply extracting 'highway' should give all of the key 
material for moving around the world ... along with waterway although in 
my mind navigable 'waterway' elements are simply highway as well along 
with railway. So fragmenting all these across other 'new' detail tags is 
simply wrong in my higher level view of the data. Pedestrian areas 
linking between road, rail and water transport DO need a little more 
consistent tagging as it is not at all easy currently to decide just 
what IS a correct set of tags to cover all pedestrian areas? It should 
not depend on which editor was used to create the data :(


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

[OSM-talk] Update email address not working?

[Lester]

Some time back I changed my email address, but missed that the 
confirmation email never actually happened. Just tried to post and of 
cause the new email address got bounced to moderation. Checked my 
profile again and have twice had the messages about watching for email, 
but as yet no email ... where next to fix this?


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] Remove validation rule asking to add highway=footway to railway/public_transport=platform

[Lester]

On 24/05/2019 09:27, Wiklund Johan wrote:

As a frequent mapper of public transport features, I agree with the opinions of 
Markus. Adding footway to the platform serves no purpose but to please poorly 
built routing engines.


Same here ...
Routing for rail passengers should be handled correctly by the routing 
engine as it's separate from 'public right of access' and access to 
platforms is an additional area that requires management separate to 
simple public footpaths?


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] iD invents nosquare=yes for buildings which should not be squared

[Lester]

On 09/05/2019 23:21, Michael Reichert wrote:

JOSM runs its validation rules only on objects modified or created in
the current session. This seems more sensible both for experienced users
and newbies for two reasons:

- Uses don't get overwhelmed with dozens or hundreds of reports on
   objects they did not touch.

- If users follow suggestions how to fix blindly (we cannot expect an
   unexperienced iD user to have the same knowledge as the average JOSM
   user), they are used as living bots running validation rules on
   randomly selected areas of the map. One might call this a hidden
   automated edit.


Been some time since I put buildings in, but surely the the right way to 
handle ADDING a square building is just to select 'box' and position 2 
diagonal corners? With the logic picking up the adjacent corners of 
another square building? This is a drawing problem rather than something 
that gets tagged to sort out later? A row of houses simply square off an 
existing wall. Editing a block of building drawn as a single block to 
provide individual units needs the right tools rather than some tag 
saying 'this block was not square last time I drew it'?


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] We're erasing our history in wiki

[Lester Caine]

On 22/04/2019 11:45, Ilya Zverev wrote:

It’s history.
Ilya ... it's the same problem we have with with a lot of the historic 
material. Personally I'd prefer to see the history accessible in some 
way, be it the history of the development of a area of mapping data, or 
the history of how we got to a particular style of recording that data. 
The data is in reality not totally lost, all that is missing is some 
general consensus on making it visible when appropriate.


There has been a request for 'namespaces' in the wiki to help manage 
such things as the historic discussions on how tags have evolved and why 
some have been rejected. I'm not sure that it is the appropriate way to 
manage it, but an historic time line view of wiki pages is something 
that would not require 'manual management' and with a switch to display 
or not deleted pages would fill the gap? People investigating a 
particular tagging development could then see the past history of 
related pages.


Doing the same with the map data is somewhat more difficult, but I still 
think it's a development that would replace the need to marry OSM with 
OHM for material that is substantially linked to current live data?


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-ca] Building Import

[Andrew Lester]

I disagree. Silence won't solve anything. 

I'm speaking here as a local BC mapper, and I strongly disagree with these 
recent imports. I thought we had a general consensus that we'd discuss this as 
a community and figure things out before restarting the import, but it seems 
that some mappers don't like having to wait or deal with other people. 
Considering that Danny seems to consider orthogonal buildings to be outright 
wrong (a position that I strongly disagree with and I think some others do 
too), there's clearly still some discussion required before imports can be 
started again. Sure, you could go ahead and import anyway contrary to other 
community members' wishes, but that sure won't make you any friends and you run 
the risk of having your changesets reverted if the data quality is too poor or 
violates the import guidelines. 

Please, please, please, let's hammer things out first before we import any of 
this data. The buildings aren't going anywhere, so there's no need to rush poor 
data into the database. If you're itching to map some things, go for a walk and 
map some addresses and businesses near you. 

Andrew 
Victoria, BC, Canada 



From: "Danny McDonald"  
To: "talk-ca"  
Sent: Friday, March 15, 2019 8:48:55 AM 
Subject: Re: [Talk-ca] Building Import 

OK, so this discussion has gone a bit off the rails. In terms of the DWG, this 
has all happened so fast - the referral to the DWG was less than 2 hours after 
the initial message, and was not in response to any actual edits I made after 
receiving Pierre's stop message. 
I suggest that we all stop emailing this list for the rest of the day, given 
the high level of tension on both sides. I will not be importing anything for 
the next week (at the very least), and I don't think anyone else will either. 
DannyMcD 

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

Re: [Talk-GB] How to map new housing?

[Lester Caine]

On 08/03/2019 15:15, Brian Prangle wrote:
Whilst being immensely useful, Planning Applications are usually heavily 
annotated as Copyright,  both Crown Copyright and Developer Copyright- 
so even if the developer gives you permission you're still lumbered with 
OS encumbrance


The site plans may use OS material, but the developers drawings don't 
and in most cases even OS don't have the new roads and other details so 
permission to use is all that IS needed.


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] Tagging post towns and other addressing issues in the UK

[Lester Caine]

On 28/01/2019 18:24, Will Phillips wrote:

On 28/01/2019 17:28, Lester Caine wrote:
The reality is that for the UK ALL we need is the Postcode to supply a 
reference to the Royal Mail 'postal address' as that is purely a Royal 
Mail invention anyway.  I personally don't see the need to add 
'addr:street' everywhere but that is what people seem to prefer. 
Adding several more addr: fields to EVERY building is just taking 
things too far? 


There are certainly occasions when the street name is needed. For 
example, I recently surveyed a single postcode (DE72 2HP) containing two 
houses with the same house name, but different street names.  Postcodes 
do sometimes cover two streets in rural areas. In these cases one might 
technically be a subsidiary street, but it's often not obvious which one.


One could say that DE72 2HP is breaking Royal Mail's own rules, but it 
is a rare exception to the rule, and often you find the street is 
actually the secondary build reference rather than the street in the raw 
data.


More generally, if we only included the postcode surely there would 
often be no way to discover the correct street without referring to 
closed proprietary data, and a key motivation for adding addresses to 
OSM is to avoid that.


I'm still of a camp that prefers a proper relational dataset rather than 
'flat file'. There is no reason we can't have tables of open source data 
that we reference and a single copy of the details.


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] Tagging post towns and other addressing issues in the UK

[Lester Caine]

On 28/01/2019 15:31, Tom Hughes wrote:
The notion that I should tag addresses in Charlbury with 
"addr:city=Chipping
Norton", a town 6 miles away, just because one private delivery 
operator[1]

uses Chipping Norton as an optional part of their addressing is... one of
the more outlandish ideas I've heard in OSM tagging circles, and that's
saying a lot.


To be fair "addr:city=Chipping Norton" would be outlandish even for
an address *in* Chipping Norton...


'city' has always been the wrong title for the field across every 
system, but it is consistent and as far as I am concerned it is the name 
of the primary location, be it 'Birmingham', 'Chipping Norton' or 
'Saintbury'. It does away with the need to make any decision on the 
'size' of the place. That additional places can be added to location to 
more accurately identify it depends on the application, so addr: may 
consist of a lot more elements than we currently cater for anyway.


The reality is that for the UK ALL we need is the Postcode to supply a 
reference to the Royal Mail 'postal address' as that is purely a Royal 
Mail invention anyway.  I personally don't see the need to add 
'addr:street' everywhere but that is what people seem to prefer. Adding 
several more addr: fields to EVERY building is just taking things too far?


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

[Andrew Lester]

I was surprised this morning when I saw that a chunk of buildings had been 
imported in Victoria, BC. The changeset linked to the wiki plan and I then 
checked my email and saw this email chain. 

The "local" (in this case the Canadian community) has not been sufficiently 
consulted. Looking back in the mailing list, there were some tangential 
discussions about some things related to this import (mostly without any final 
consensus), and then a single email stating that the import plan had been 
created and sent off to the imports list 
(https://lists.openstreetmap.org/pipermail/talk-ca/2018-November/008864.html). 
After that, nothing. I can't find any emails related to this import that were 
linked to both the imports and talk-ca list, nor are there any that bring back 
the results from the imports list for those who aren't following that. There 
also wasn't any notification that the import was actually going ahead. I'd 
consider all of this to be a major failure of the "Community Buy-in" section of 
the Import/Guidelines. 

For such a major import, we should be going above-and-beyond to make sure every 
possible aspect has been addressed adequately. The lack of confidence from the 
general OSM community as a result of the botched import in Ottawa and the 
ongoing dislike of our CANVEC imports means we need to treat this import with 
kid gloves. We should be striving to ensure that there's no reason why someone 
could look at this import and find faults with it. That may seem like a lofty 
goal, but we're talking about a building import for the second-largest country 
in the world. 

Once the administrative portions are dealt with and the community has been 
sufficiently consulted, the technical area needs to be looked at. Now that I've 
seen some of the data in action, there are various issues that need to be dealt 
with. Some that became immediately apparent on the data imported in Victoria, 
BC include: 
-A significant number of unsquare buildings (JOSM validator reports this as an 
Other/Building with an almost square angle). Of an estimated 935 buildings in 
this chunk, 692 have almost-square angles. Looking more closely and running the 
JOSM Orthogonalize tool on a sampling of buildings, I believe all of them have 
unsquare angles. This may be the result of rounding errors in data conversion 
and should be fixed in the source data before importing. 
-Inconsistent tagging (some houses are building=yes, some are 
building=detached) 
-A need for simplification (extra nodes in nearly-straight segments that are 
straight in reality) 

I'd suggest the following plan: 
1. Update the tasking manager to indicate in clear terms that this import is on 
hold and no data should be imported at this time. Ideally, the tasking manager 
should be taken down entirely so no data can be imported. 
2. Send a clear, unambiguous email to the talk-ca list indicating that this 
import is being planned and to solicit feedback. 
3. Wait. THIS IS IMPORTANT! The community needs to be given time to see that 
this import is being planned, and to discuss the many aspects related to it. 
For such a major import, silence-as-tacit-acceptance doesn't fly. There are 
local communities out there that need to be brought in to the process. If 
necessary, figure out who the active contributors are in various jurisdictions 
and contact them directly. 
4. Figure out the technical details. It's only after the import had already 
started that people are now talking about conflation and data quality. These 
need to be figured out, a plan documented, and the source data cleaned. Tags 
also need to be clarified. The current wiki plan gives almost no guidance about 
how to actually perform the import. 
5. Only after all of the above has been figured out, let the community know 
that the import is actually going ahead. 

Come on, people. We can do a lot better than this, and definitely should. Let's 
make this a shining example of why imports can be a good thing for OSM, not 
provide fodder for those opposed to them. 

Andrew Lester 
Victoria, BC 


From: "John Whelan"  
To: "Nate Wessel"  
Cc: "talk-ca"  
Sent: Saturday, January 19, 2019 5:07:52 AM 
Subject: Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel 

I'm saying when the matter was first raised on the import mailing list as a 
heads up I made reference to the existing Ottawa pilot and gave a link 
basically saying we would be following the same pattern. There was considerable 
discussion around the Ottawa import plan both on the import plan and talk-ca 
and the Ottawa import which I didn't draw up. Later there was a formal link to 
the data import plan. 

So two stages if you like. This is what we are thinking of doing and this is 
how we intend to proceed. 

Cheerio John 

Nate Wessel wrote on 2019-01-18 11:38 PM: 




John, 


I'm sorry to keep saying this, but I really do not think this is an acceptable 
import ap

Re: [Talk-ca] canvec imports

[Andrew Lester]

I agree. A selective import from CANVEC is fine and generally gives good 
results. As long as you don't import things like forests and buildings (which 
are both woefully out-of-date, broken, or outright wrong), there usually isn't 
a problem. However, if someone just imports an entire block of data without 
inspecting it, that's when we run into the visible issues that the peanut 
gallery picks apart. 

Andrew 
Victoria, BC 


From: "James"  
To: "Andrew"  
Cc: "talk-ca"  
Sent: Tuesday, November 27, 2018 9:58:19 AM 
Subject: Re: [Talk-ca] canvec imports 

not sure why Canvec always gets shat uppon, their water features are great and 
pretty accurate, the forest/landcover on the other hand needs fixing before 
import. I think it's clear enough on the canvec wiki page that only experienced 
mappers/importers should attempt a canvec import. 

On Tue., Nov. 27, 2018, 12:54 p.m. Andrew < andrew.alli...@teksavvy.com wrote: 


FYI Canada 

I made a few imports to canada a while ago and apparently 
raised the ire of someone. 

Here we go again :-( 

--- 
This was the first message 

>>Please, fix issues caused by this changeset for example in region of 

Yup, that was it, I was like ok, whats wrong with the changeset? Found 
an overlapping way. Figured that was it :-) 

And now 

Where is documentation page of this import? Can you link to discussion 
done before this import started? 

And So On. 

--- 
Hi PurpleMustang, 

XXX X has sent you a message through OpenStreetMap with the 
subject Re: Canvec Import: 

XXX X 
On 2018-11-27 17:21:34 UTC PurpleMustang wrote: 

Hello: This import has been a work in progress for about 10 years now 
:-) 

https://wiki.openstreetmap.org/wiki/Import/Catalogue 

https://wiki.openstreetmap.org/wiki/Geobase/Announcement 

Andrew 

Note that currently active import should have a wiki page describing 
what exactly is imported and how data is processed - see 
https://wiki.openstreetmap.org/wiki/Automated_ 

 

Oh Well Here we go again 

Andrew 
aka CanvecImports 


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




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

Re: [Talk-GB] How to map houses

[Lester Caine]

On 27/11/2018 11:40, John Aldridge wrote:
It would be useful if there was a means of splitting buildings in the 
editor(s).


I'm probably in a minority here, but since the mapper usually can't tell 
how the building is divided internally, it's more honest to leave the 
building undivided and put the housenumber etc. tags on nodes on the 
building boundary which represent the front doors.


I also think this is more useful to someone using the map, as it shows 
where to find the doorbell!


My source material has all the house divisions and we could even include 
the internal floorplans, but where we have a block of houses being able 
to quickly draw an outline and then create several objects with the same 
set of tags is easier than trying to manually create each linked element 
of the building.


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] How to map houses

[Lester Caine]

On 27/11/2018 08:47, Ed Loach wrote:
'We expect this "interpolation way" to be a temporary construct. In the 
long run, OSM will have every single house mapped as a building outline, 
and every single house will be tagged with its house number, so that 
interpolation ways will gradually vanish. However they are good to make 
a quick start with house numbers, and reportedly there's existing data 
waiting to be imported that will also require interpolation.'


It would be useful if there was a means of splitting buildings in the 
editor(s). Even for semi-detached houses, being able to create two 
objects from the one original outline would be helpful. A terrace of 
houses just needs to identify how many new objects to create. Where I 
have been adding buildings this has been the irritation. Mirror would 
also be useful although architects seem to like making changes between 
the two halves of a semi these days. But draw one half with all it's 
tags then mirror to create the other half, and just edit the house number.


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?

[Lester Caine]

On 22/11/2018 18:53, Victor Shcherb wrote:
In that case I would actually support idea of deleting all country 
boundaries to avoid this question completely.


There are numerous sets of data within OSM that are disputed and one 
'controlling body' or another would prefer was not published at all. The 
best that can be done is for local displays of that data to provide 
local filters. Simply deleting data is never going to be the right 
solution, but allowing tools that censor the data is equally controversial.


For the point of view of OSMAND, the display needs to know where one can 
drive and where one will be stopped and need paperwork to proceed. THAT 
in my book is the simple ToTG because it is flagged by something 
physical. That some areas don't actually have 'border posts' does create 
a problem, but as an 'outside visitor' to the Ukraine or Cyprus, where 
can I drive and where could I run into difficulty if I do drive into a 
disputed area. It's the grey areas that are something that will cause 
problems and may require projects like OSMAND to censor data based on 
the user view? I doubt that OSM services are really able to manage this 
area in a generic way?


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] Plus code grid service

[Lester Caine]

On 19/11/2018 17:16, Rasťo Šrámek wrote:
A plus code is not intended to have the same function as latitude and 
longitude. It is intended as a replacement for "street name, house number"
address parts where those don't exist and cannot be reasonably created.  
If you write

Firstname Lastname
WF8R+H6 Praia
Cabo Verde

on an envelope and drop it off at your local post office, wherever you 
live, it will be delivered.


As long as they know just which code system you are using. This is just 
another in a long list of 'postcode for no postcode' areas. Have any of 
them actually gained traction on the ground?


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] Network tag on railway stations

[Lester Caine]

On 17/11/2018 17:26, Colin Smale wrote:
Surely the infrastructure network is a different concept to the train 
network?

The UK overland railway network is managed and owned by network rail.


How about this for a thought:

For the trains, a network might be linked to a brand; An operator may 
have distinct branding for commuter services, intercity services and 
freight operations giving three different "networks." All the services 
within a network will be integrated in terms of scheduling and other 
planning, whereas coordination with other networks is a whole different 
can of worms. If there is just one big team doing the planning, then 
it's one network. If the planning is done reasonably autonomously, then 
they are different networks.

All investment in the overland rail structure is via Network Rail

Is "London Overground" a separate "network" to the Underground? Is the 
DLR a separate network? Instinctively I would say yes to both of these, 
from both a train service point of view and from an infrastructure point 
of view. Pleased to hear arguments to the contrary though.


There are other networks such as the such as Midland Metro, Dockland 
Light Railway and London Underground as well as other metro/tram 
networks. These tend to be owned and run by local transport authorities. 
Transport for West Midlands for Midlands Metro and TFL Transport for 
London for DLR and London Underground. These manage both the rolling 
stock and the tracks while Network Rail does not actually own any 
rolling stock - as far as I am aware - except perhaps for maintenance 
vehicles, although I would not be surprised if the maintenance companies 
owned them!


So DLT has a network=Transport for London and an operator=Transport for 
London ... in my book. The other metro lines are similarly owned and 
operated.



--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] Network tag on railway stations

[Lester Caine]

On 17/11/2018 14:46, David Woolley wrote:

On 17/11/18 14:36, Lester Caine wrote:
Who operates the station, and who operates on each line accessing that 
station. The various ID's would help keep this data up to date.


You need to distinguish between operating the line and operating 
services over that line.


On the lines ...
network='operating the line'
operator='operating services over that line'

Stations will also have
operator='station services'

I think 'National Rail' does not fit either of those definitions? So 
network=Network Rail ... or one of the Metro services?


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] Network tag on railway stations

[Lester Caine]

On 17/11/2018 10:02, Tony Shield wrote:
Ormskirk is a good case where Merseyrail manage the station - 
essentially the operator in OSM parlance.


I picked Ormskirk is it is the terminus for both Merseyrail and Northern 
services on that line. They terminate here as the Merseyrail line is 
electric and the Northern line is still served by diesel trains. I'm not 
sure today, but certainly originally the break was simply a buffer 
placed on the line ( must be 45 years sinse I was there last ;) ) which 
could be removed at some point to restore through running. Hence the 
suggestion that the line north be tagged with the operator=Northern, but 
as Michael suggested there may well be a case for multiple operator tags 
on the lines.


There is a good catalogue of data on the rail system, but I'm not sure 
it's all suitable to be used. It would be nice to see a 'UK' guide to 
tagging which covers all the options. Who operates the station, and who 
operates on each line accessing that station. The various ID's would 
help keep this data up to date.


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] Network tag on railway stations

[Lester Caine]

On 17/11/2018 07:12, SK53 wrote:
I've just come across a large number of instances of network=Nation Rail 
on stations. Clearly this is a mistake, presumably National Rail is 
intended.


As the station concerned is heavily branded with Merseyrail my first 
instinct was to change the tag to this, but then I wondered if National 
Rail is more useful. Today a network=Merseyrail would be more useful to 
me because I have a day rover for that network.


I wonder what others think, and can we clean up the erroneous name?


Merseyrail is the operator rather than the network. The network is owned 
and managed by Network Rail. National Rail is simply a  club of 
operating companies and includes both Network Rail and Merseyrail. So 
every station should have an operator=xxx and network=Network Rail, but 
they should also have some tag to the other train operators using the 
network through the station if more than 'National Railway' member is 
using it. So Ormskirk Station 
(https://www.openstreetmap.org/way/86878104#map=19/53.56928/-2.88114) 
for example needs an operator=merseyrail and *I* would prefer 
network=Network Rail. The line north should be tagged operator=Northern 
which would at least associate that fact with the station, but other 
stations may have more than one train operator using the track. Network 
Rail and National Rail is probably interchangable in the public mind, 
but freight services use the track and is not covered by National Rail, 
but it's unlike that stations like Ormskirk would have that problem ;)


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-ca] Exit with name on node *and* destination

[Andrew Lester]

I just cleaned up a handful of junctions in the western provinces where refs 
were in the name tag, destination was in the name on the junction in addition 
to the link way, etc. Running an Overpass query for all of Canada 
(http://overpass-turbo.eu/s/DrL) now shows that there are almost 2000 of these 
in Ontario and Quebec, 2 in Nova Scotia, and 1 in Newfoundland. The last 3 look 
legitimate, but a quick scan of the ones in Ontario and Quebec shows that most 
are clear tagging-for-the-renderer. In a few test cases, the destinations are 
already on the link ways, so there's no need for the destination to be in the 
name on the junction nodes. 

Does anyone have a good reason for keeping these as they are? My opinion is 
that these should all have the names removed when it's clearly the destination, 
and that this destination info should be added to the link way if it isn't 
already. 

Andrew Lester 
Victoria, BC 


From: "Martijn van Exel"  
To: "talk-ca"  
Sent: Tuesday, November 6, 2018 7:56:23 AM 
Subject: Re: [Talk-ca] Exit with name on node *and* destination 

So apparently this is pretty common practice in Quebec. There are 755 junction 
nodes that have name tags. See https://overpass-turbo.eu/s/Dr9. Other provinces 
don't have nearly that many. 

The user breakdown for latest edit on those nodes doesn't really surface one 
mapper who consistently added these tags. See https://overpass-turbo.eu/s/Drf 

I'm inclined to leave it to the local Quebec community to say something more 
definitive about what, if anything, needs to be done with these name tags... 
I'm happy to set up a MapRoulette challenge to enable us to systematically look 
at these nodes.. 

Best, 
-- 
Martijn van Exel 
m...@rtijn.org 

On Tue, Nov 6, 2018, at 08:33, Martijn van Exel wrote: 
> Is there an Overpass or other query that could detect all these 
> situations? I could make a MapRoulette challenge out of them so we can 
> look at them together and remove the name on nodes where it's not 
> appropriate / redundant. 
> 
> I'll ask on IRC as well.. I am not that much of an expert in Overpass. 
> -- 
> Martijn van Exel 
> m...@rtijn.org 
> 
> On Mon, Nov 5, 2018, at 18:23, Jarek Piórkowski wrote: 
> > Yep, so in this case removing the name and keeping the ref on the 
> > junction node sounds appropriate. 
> > 
> > While we're at it, the service road 
> > https://www.openstreetmap.org/way/48154169 doesn't seem to show up on 
> > any of the current imagery in iD. Does it still exist? 
> > 
> > --Jarek 
> > 
> > On Mon, 5 Nov 2018 at 16:28, Pierre Béland  wrote: 
> > > 
> > > Je disais précédemment 
> > > > Je ne sais pour les autres provinces, mais au Québec les no. de sorties 
> > > > correspondent aux bornes kilométriques de la route (ici 15 pour km 15). 
> > > > Il est plus informatif d'afficher le no de sortie (ref=15) 
> > > 
> > > 
> > > Ici c'est sortie 11pour km 11, et non 15 comme j'ai dit précédemment. Sur 
> > > la carte, la numérotation de la sortie était «noyée» sous le texte. 
> > > 
> > > 
> > > Pierre 
> > > 
> 
> ___ 
> Talk-ca mailing list 
> Talk-ca@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-ca 

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

Re: [Talk-ca] Dartmouthmapmaker

[Andrew Lester]

I'm not sure how helpful that article would be, considering that it focuses on 
building tagging, but this user is primarily working on admin boundaries and 
highways. 

John, I'm surprised that you were able to successfully have a discussion with 
them. A number of other contributors have tried to communicate with them 
through various means, but they either didn't respond or responded in a way 
that demonstrates they clearly don't understand what's happening. The fact that 
they refused to communicate is what led to the current block, and I'm not 
confident that they'll suddenly change their ways once the block ends. I guess 
we'll see what happens in a couple of days. 

Andrew Lester 
Victoria, BC 


From: "OSM Volunteer stevea"  
To: "john whelan" , "talk-ca" 
 
Sent: Thursday, November 1, 2018 9:54:40 AM 
Subject: Re: [Talk-ca] Dartmouthmapmaker 

Being as gentle (though not local) as I can be, I continue to assert that our 
wiki for BC2020 in general and 
https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Building_Canada_2020#The_data_that_could_be_mapped
 as a specific section IN that wiki (calling attention to these tags, with 
hundreds of potential values): 

building 
man_made 
addr 
start_date 
entrance 
amenity 
and others 

might prove very helpful starting points. Often the simple act of reading OSM's 
built-in wiki documentation is one of the best, if not THE best starting point. 
Of course, talk- mailing lists, our forum and many other sources of 
advice/documentation/help are available, too. 

Regards. 
SteveA 
California 

> On Nov 1, 2018, at 9:40 AM, john whelan  wrote: 
> I've discussed the Open Data side with them but I think they could do with a 
> bit of guidence on the tagging side. Could someone ideally more local than I 
> point them gently towards map features and more standard tagging? 
> 
> I must confess my knowledge of tagging is a little limited to highways and 
> buildings. 
> 
> I get the impression they are open to dialog if treated gently. 
> 
> Thanks John 
> ___ 
> Talk-ca mailing list 
> Talk-ca@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-ca 


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

Re: [Talk-ca] Nova Scotia imports, and boundary=land_area

[Andrew Lester]

Hi Frederik, 

What this mapper is doing is not usual or desired. As you've seen by the 
changeset discussions and edit wars, the general OSM community does not agree 
with the way they're doing things. I sent them a message a few days ago 
pointing out a number of the issues you listed and suggesting that they take a 
break from adding new data to go back and fix these issues, but I see that 
they've continued to import with the same issues, and they haven't replied to 
my message. Based on what I've seen and read, I suspect: 
1. They only have a basic understanding of OSM, and certainly not enough 
knowledge or experience to be making the type of mass-edits they are. 
2. They may be mapping for the specific purpose of Garmin GPS map use, and as a 
result are misusing tags to fit that usage rather than changing their Garmin 
map generation process. 
3. They may not even be living in Nova Scotia (some of what I've read implies 
that they're mapping remotely and English may not be their primary language). 

At this point, I think it might be a good idea to have the DWG step in. Clearly 
this mapper isn't going to stop what they're doing based solely on 
communication from other mappers. It's already going to take a while to clean 
up the mess they've made, so we need to stop the creation of even more mess. 

Andrew Lester 
Victoria, BC, Canada 


From: "Frederik Ramm"  
To: "talk-ca"  
Sent: Sunday, October 21, 2018 6:18:24 AM 
Subject: [Talk-ca] Nova Scotia imports, and boundary=land_area 

Hi, 

there's a mapper in Canada - Darthmouthmapper - who seems to: 

1. import data from a source he calls "Nova Scotia Open Data" - I am not 
aware of any imports discussion, and the source specification is not 
precise enough to determine the legal status of that. Judging from past 
changeset comments, whatever imports procedure is used must have a 
number of flaws. 

2. import administrative boundaries 

2a. as a mesh of closed ways (where most people would prefer relations), 

2b. with, among other things, the tags "_Shape_Area_=yes", 
"addrcountry=Canada" (no colon!), "addr:postcode" (which is not 
generally used for objects that do not represent an address), and 
"type=land_area" (which is not generally used on closed ways). 

2c. The combination of a level-8 admin boundary and place=village is 
also unusual (eg https://www.openstreetmap.org/way/616463020) but I 
cannot judge if this is normal in Canada. This is also used in 
residential areas https://www.openstreetmap.org/way/636390857 - is this 
area really a "village"? 

3. use a ton of is_in tags which are highly unusual nowadays 

4. occasionally change existing relations (not ways) from type=boundary 
to type=land_area (https://www.openstreetmap.org/relation/8417484/history) 

5. add addr:postcode and addr:province to place=village nodes 

6. revert corrections applied to this by other users, claiming that "The 
video and instructions state these can be part of the ways" 

A number of people have complained in the past 
http://resultmaps.neis-one.org/osm-discussion-comments?uid=698649 
but many of the issues seem to be present still. 

Before I ask him to fix this -- are any of the behaviours / mapping 
techniques outlined above somehow usual in Canada? 

Bye 
Frederik 

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

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

Re: [OSM-talk] Really heavy browser load with Overpass-turbo map display

[Lester Caine]

On 24/09/2018 20:36, Dave F wrote:
Switching to an older version of a browser isn't neutral and raise 
security considerations as always.


Usability is the same & 61.0 works OK & is only 2 months old. Personally 
I wouldn't rely on browser security.


There are a number of problems resulting from the major surgery Firefox 
recently went through which are only slowly getting fixed. It would have 
been much more sensible to maintain the original build in parallel until 
more of the core functions and disabled extensions were made functional 
and compatible. I'm still struggling with the lack of Firebug as the 
replacement has problems with font sizes at least on linux and does not 
provide some of the nice features Firebug STILL provides on my 
development machine.


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Lester Caine]

On 20/09/2018 19:44, Mark Goodge wrote:

Then get involved and put it in OHM.
I was involved, but the current OHM development is not going in a way 
that works well with OSM so I gave up. I'd rather mirror OSM directly 
and add my historic material to that local copy! Which is what I'm doing 
currently ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Lester Caine]

On 20/09/2018 17:50, Mark Goodge wrote:
In fact, putting them in OSM isn't just damaging to OSM, it's damaging 
to OHM. At the moment, OHM is a bit sparse, there are some well-mapped 
areas but there are some pretty big blank areas. What it really needs is 
a group of enthusiastic contributors, who are knowledgeable about 
history and want to see it mapped. Putting the historic counties into 
OHM would be a huge boost for it, it would make OHM much more useful for 
genealogists, fans of listed buildings, ancient monuments, old railways, 
etc. And there are plenty of those. That in turn would drive more users 
of OHM, and more contributors, thus helping to make it even more useful.


Until OHM has all of the current history available in parallel with 
'extra' data it's not worth spending any time on. I want to see where 
historic changes fit around the current state on the ground so I work 
off OSM ... and will until all that data is available in OHM ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Lester Caine]

On 20/09/2018 07:24, Frederik Ramm wrote:

Surely your argument which seems to be based on the romantic
"Rutland that people feel in their hearts" could not be applied as a
reason to store "Rutland County Council District Council in the borders
of 1997", plus "Rutland County Council District Council in the borders
of 1999", and also "Rutland County Council District Council in the
borders of 2003"...?


That people have a desire to view this data is a simple fact. Had the 
1997 boundary been drawn at that time, and then update to '1999' and 
subsequently to '2003' means that this data would have been in the 
database and as others keep pointing out would be accessible by looking 
at the change logs. The next changes will also be logged the same way, 
but ACCESSING the historic views is not an easy process?


The current 'process' dictates that OHM should take over the job of 
displaying the older versions but there is currently no easy way to 
carry out that process, and these 'special cases' then have to exist in 
parallel across both databases. So is there not a good reason to start 
processing 'start_date' and 'end_date' properly so that an object CAN 
exist in different configurations over time. Material which has an 
'end_date' is ignored by any 'current map' processes in which case a 
'special case' historic element would be named as such and not have an 
end_date ...


Current data will become superseded, and one is then adding the new 
version, but the old version is still valid data and needs to be handled 
better than it is currently. If the process is managed properly then 
adding additional historic data should not be a problem since the vast 
majority of that data will simply be a 'start_date' for objects that ARE 
current in the database!


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] Wickham Market, Suffolk

[lester]

Sent from MailDroid

-Original Message-
From: Mark Goodge 
To: talk-gb@openstreetmap.org
Sent: Fri, 07 Sep 2018 11:32
Subject: Re: [Talk-GB] Wickham Market, Suffolk



On 07/09/2018 11:25, Martin Wynne wrote:
>> If it were true, then almost every village would need 30mph repeater 
>> signs throughout, as they wouldn't have enough lighting to count as a 
>> built up area. In practice, though, they don't.
> 
> Yes they do. At least all the villages I know have 30mph repeaters. 
> Here's a couple at random:
> 
>   https://goo.gl/maps/zMfNHUFTSW92
> 
>   https://goo.gl/maps/N96GbyndYRB2

None of the villages round here do. Nor do any of those I've lived in 
previously.

(Quoting crap on mobile clients!)
Broadway is still a village in my book, and had to sort speed limit signs when 
speeding tickets were found invalid. In some ways the facebook singular 'city' 
designation makes some sence. 
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] un-named roads in UK

[Lester Caine]

On 29/08/18 21:21, Jubal Harpster wrote:

Stadium Mews

https://www.openstreetmap.org/way/260127900

https://goo.gl/maps/JJNxamCgLy12

_https://binged.it/2C0LAw1_


PAF file ... N5 1FP

--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] Representing places with no housenumber

[Lester Caine]

On 23/08/18 10:16, Mark Wagner wrote:

As a rather extreme first-world example, the address of
https://www.openstreetmap.org/way/132723167  is:

name=Grand Canyon North Rim Lodge
addr:city=North Rim
addr:state=AZ

Not only does the building not have a house number, house name, or
other house identifier, the road it's on isn't named either.  When
there's only one road in town, and that road only has one building that
receives mail, you don't need much in the way of identifiers.


But I see nothing wrong with that. MANY places the name is also the 
building name ...


I don't think anybody is saying there HAS to be a building number and if 
they are then THAT is the error. Many rural buildings simply have a name 
which in the case of the UK gets listed in the PAF file and I would 
simply expect 'Grand Canyon North Rim Lodge' to be the address if USPS 
had a similar postal address listing?


I find the practice of adding ANY tag that does not enhance the data as 
pointless. There is no need to TAG that there is no number ... you just 
don't add the tag ... just as the example here ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] 'C' class roads references.

[Lester Caine]

On 16/08/18 14:24, Dave F wrote:

A contributor has been reverting my changesets over the past few days:
https://www.openstreetmap.org/user/tms13/history#map=7/56.741/-4.252

https://www.openstreetmap.org/changeset/61655207
https://www.openstreetmap.org/changeset/61623830#map=11/56.4828/-3.2425

As I don't wish to get into an edit war & believe blocking is a last 
resort, would it be possible if a couple of others attempt to help him 
understand the reasons.


On what basis is 'highway_authority_ref' being put forward since I don't 
think the councils who allocate the references for C and U roads are 
actually the 'highway_authority' but are responsible for those roads NOT 
designated as the responsibility of the 'highway_authority' ... at least 
that is my reading of the situation. These references are 
'local_authority_ref' and are not unique from one part of the country to 
another while 'highway_authority_ref' suggests a more central management?


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

[Lester Caine]

On 11/08/18 07:02, Andrew Harvey wrote:
 > No, all highways are areas :) Mapping them as a line is a manual 
generalization ;)


Yes, but you're mapping the road centerline, which isn't a 
generalization but a real world feature.


Mapping the path of a highway as a 'way' is a generalization. This can 
be extended by adding additional tags to describe all the fine detail 
such as width, number of lanes, associated cycle and footpaths, and so 
on, but this is a simplification to the actual fine detail. I'll repeat 
what I said, 'highway' SHOULD only be attached to a way and not to areas 
so that we have the simplification for lower resolutions of the data. 
ADDING areas to map the fine detail that is associated with the 
information also contained in the additional tags should be tagged by 
association and not by adding additional 'highway' tags to the areas. IN 
THAT CASE area=yes could be used to identify that there are associated 
area objects that can be used on higher resolution mapping. I don't 
think 'area:highway=' has place especially where the 'centerline' way is 
used to combine several highway=xxx types such as road,cycleway and 
footpath ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Lester Caine]

On 08/08/18 17:03, Nick Whitelegg wrote:


I think these things are at least partly a product of what generation 
you belong to.


I think one can include 'Middlesex' in that package? Just when will it 
cease to exist ;)


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Lester Caine]

On 08/08/18 13:54, Colin Smale wrote:
There are plenty of examples of "former" objects in OSM - closed pubs, 
railway alignments etc. They are only still there because they are 
perceived to have some kind of relevance in the present day. Can a case 
be made that these historic counties are still "relevant" today?


I'm listening to the steam trains pulling in and out of Broadway station 
at the moment. This was a 'disused' line and there was talk about 
removing that sort of data from OSM. The line out of Broadway goes on 
north and still has a designated use of 'disused railway'. I don't know 
if the line will ever be extended, but in some peoples minds it's on the 
cards as it could eventually link to Stratford Upon Avon. That end of 
the line has now been built on so a new terminus would have to stop 
short, but knowing where the line used to run through that house estate 
is interesting to some.


Even a pub has a place in the tracking of genealogical data and if one 
has some means of showing a current map with the location of previous 
events it's a useful tool. OHM is trying to do that, but since every 
change in OSM has to be mirrored to OHM I find this very counter 
productive ... YES there is a need for separate layers of data such as 
the battles of the second world war, but all should have a single base 
in OSM and where key parts of the two combine, the current OSM map 
continues to display them. Purely using OSM data to show the development 
of a town over time potentially needs very little 'historic' data other 
then 'start_date' ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Lester Caine]

On 08/08/18 12:59, Dave F wrote:
How often do you believe people will actually want historic data? 
Organizations archive for a reason. Consider your house, how things you 
don't use will get shoved to the back of the cupboard/shed.
I live in a Roman city, the editors struggle to display current data. 
Imagine what it would be like if *everything* was shown back to the days 
of Emperor Nero.


We have the same problem all over the place in keeping historic data 
accessible. The argument is always 'How many people will use it' or 
'Does it matter if we ignore that' :(


Even providing verifiable timestamps for historic events is a gamble 
since the timezone database hides verified data prior to 1970 'because 
it's outside the remit'! In which case one needs a reliable source for 
time offsets even as recently as the 2nd world war because those 
provided by TZ are known to be wrong ... but nobody provides it :(


The fact that there was Roman settlement in an area is very useful data 
for a planning department to know if a full archaeological report is 
needed. My own genealogical research would be helped if CURRENT data had 
a start_date and then one could see if a street being referenced 
actually existed at the time ... that is one for OSM rather than OHM 
except the street may have been 'moved' or renamed, at which time the 
historic element may become important. And knowing if the street on the 
current map was in a different county is also important data. But where 
do you go to find out.


There is no clear distinction as to what is current and what is historic 
data. They intertwine and a single documented view of all the data 
including that which is becoming history on a daily basis should be the 
target, rather than saying 'It's too difficult so lets ignore it'. It's 
not difficult for a computer to manage and if people have the desire to 
start filling in all the gaps then they should be supported, not told to 
go away?


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] 'C' class roads references.

[Lester Caine]

On 08/08/18 11:49, David Woolley wrote:
I think people are overlooking the original use case for suppressing C 
references, which was that they confused satellite navigator users. As I 
pointed out before, this is really an attribute of the particular turn 
onto the road, not the road itself.  The fact that a road (A, B, or C) 
may have its reference displayed somewhere along it is not going to help 
if someone approaching the turn cannot easily see that reference.


That is little different to being told to 'turn right into "this" road' 
where most of the time one can't see a road name. It is perhaps a matter 
of identifying just which turns have a visible sign and which do not, 
and that can often apply even to A roads? But even if there is no 
signage, giving some road details is better than a simple 'turn right'? 
Many of main link roads around here don't have names or numbers 
displayed, but one still use them to avoid several miles of 'detour' via 
primary roads because the sat nav does no accept them as a 'fast route'. 
OSMAnd is a sod for that problem :(


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Lester Caine]

On 08/08/18 10:56, Dave F wrote:


On 08/08/2018 09:54, Lester Caine wrote:
we are now in a situation where much accurately mapped material is 
simply dumped when there is a change to the current situation.

1. it's not dumped, it's still in the database as a historic version.
2. Changes almost always increase the accuracy & detail of the database.


Going back through the change logs is not the easiest process? Isolating 
deletions that are due to historic changes rather than simple factual 
corrections also muddies the water. But making the link to OHM more 
organised would allow current valid data to be archived properly?


The 'delete' process should be handled in a manor more sensitive to 
the hard work that has gone before!


the vast majority of the material making up the historic data such as 
boundaries IS the same as the current 'live' data.


I'm unsure that's true, but if it were, why duplicate?


That was always my argument AGAINST OHM ... since much of the data 
making up boundaries has not changed, having to duplicate that 
information over to OHM, and then decide where material is current or 
historic means that IDEALLY OHM is a complete copy of the OSM database, 
but with the historic material easier to find than via change sets ... 
why not just manage a single database? People who don't want access to 
historic material simply ignore data which has 'expired' via end_date.


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Lester Caine]

On 07/08/18 20:48, Dave F wrote:


User smb1001 is currently adding county boundary relations with 
boundary=historic through out the UK:

http://overpass-turbo.eu/s/ASf (May take a while to run)

Changeset discussion:
https://www.openstreetmap.org/changeset/61410203

 From the historic wiki page
"historic objects should not be mapped as it is outside of scope of OSM"

Frankly I don't buy his comments. The problem is where to stop? Do we 
have ever iteration of every boundary change since time immemorial? Then 
what about buildings, roads, or coastline changes etc? The database 
would become unmanageable for editors (it already is if zoomed out too 
far).


I think these edits should be revoked.


They should be moved to OHM but then ANY information that is superseded 
should be automatically archived to SOMETHING since we are now in a 
situation where much accurately mapped material is simply dumped when 
there is a change to the current situation. The 'delete' process should 
be handled in a manor more sensitive to the hard work that has gone before!


I have always disagreed that 'historic changes have no place in the 
database', since the vast majority of the material making up the 
historic data such as boundaries IS the same as the current 'live' data. 
Simply not downloading data that has a prior end date does not make 
anything 'unmanageable', in fact it makes life a hell of a lot easier 
since one can simply tag a section of the boundary as 'end_date=xxx' and 
add a new section with the boundary change as 'start_date=xxx'. The ONLY 
question is what happens to the data once it has an end date ... which 
may be some time in the future ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] 'C' class roads references.

[Lester Caine]

On 08/08/18 08:30, Andy Townsend wrote:
There are combinations that aren't handled perfectly (especially where 
roads have a mixture of different refs) and I'll look at some of these 
edge cases later.  Hopefully though as things stand it's useful to 
people who really want to see these "official" refs.


I think this is part of the 'UK' problem. While some reference numbers 
are not displayed 'on the ground', increasingly they ARE being used in 
official announcements such as accident reports, road closures, planning 
applications and the like so that the relevant authorities know they are 
talking about the same stretch of road, but that does not help us 'mere 
mortals' unless someone actually publishes a map to show the situation 
on the ground. That OSM IS in a position to fill this hole where often 
even the official maps do not because OS does not provide a rendering 
using them is just another plus for OSM. But I have no problem accepting 
that this should be on a UK specific map rather than something dumbed 
down for the whole world ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] 'D' class roads references.

[Lester Caine]

On 06/08/18 08:37, Robert Whittaker (OSM lists) wrote:

On 5 August 2018 at 19:50, David Woolley  wrote:

The only place for which I am aware of national legislation making certain
government publications automatically free to use is the USA.

Thanks to the EU, we do however have the "Re-Use of Public Sector
Information Regulations 2015"
http://www.legislation.gov.uk/uksi/2015/1415/contents/made  . You have
to ask for permission, but if the copyright is owned by a UK public
body, they need a very good reason not to allow re-use under an open
licence, and the options for charging are very limited for most
bodies.


That I think is the one that restricting access to both the NSG and NLPG 
falls fowl off, especially when councils are required by law to provide 
it but not paid to do so. Once we can freely use at least the National 
Street Gazetteer many of the 'problems' go away and we just need to add 
the USRN reference to each way in the UK


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] 'D' class roads references.

[Lester Caine]

On 05/08/18 14:44, Richard Fairhurst wrote:

Rob Nickerson wrote:

Dave can you do the D class roads too. Someone has added these -
e.g:https://www.openstreetmap.org/#map=18/52.21554/-1.87663


And D designations will be reused in other areas ... I have seen a 
couple more D5383 such as D5383, Johns Road, Bugbrooke but possibly not 
in OSM ... these designations ARE used in publicly published reports.



That reminds me - there's some weird ones in Hillingdon too:
https://www.openstreetmap.org/#map=15/51.5603/-0.3943


https://www.hillingdon.gov.uk/media/28177/List-of-classified-roads/pdf/JW-LIST_OF_CLASSIFIED_ROADS.pdf 
is probably the source of those designations ...



Can anyone think of a location in mainland GB where
tertiary/unclassified/residential roads_should_  have a (non-A/B[1]) ref?
Milton Keynes has its (signposted) H and V numbers for Horizontal/Vertical,
but other than that I can't remember any.


Interestingly, from the guidelines ...
C road 
–
another term for a classified unnumbered road. Any numbering 
system around C roads is peculiar to the authority and is not coordinated on a 
national basis; as a result, we advise that it is not displayed.



D road
–
another term for an unclassified road. Any numbering system around 
D roads is peculiar to the authority and is not coordinated on a national basis; 
as a result, we advise that it is not displayed.


So we end up with data that should not be displayed ... but is still 
valid data in terms of the database!


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] 'C' class roads references.

[Lester Caine]

On 04/08/18 10:07, Philip Barnes wrote:
It seems to me that, in the UK, class C roads should be exactly the 
set of roads with highway=tertiary, so there is no need for a new 
tag.  Even if that is not true, the correct solution would be to test 
the reference in the renderer and suppress it if within the UK.
That really is not a pratical solution, OSM is an Internaional project 
and the standatrd renderer is International. It is unreasonable to 
expect the hard working rendering team to support country specific 
rendering.


As I said previously, if you want to see C road references rendered, 
make your own renderer.


Not many countries seem to have 'highway=tertiary' but those that do 
expect them to be rendered, and any reference they use should be 
rendered with them? This is not simply a 'UK' question, but one on how 
generic 'ref' tags are handled, and as I said ... 'highway=secondary' 
references can suffer from the same problem of not actually being 
displayed on the ground. So how the renderers handle this element is a 
world wide problem, and perhaps 'display_ref=no' would be appropriate in 
some areas of the world?


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] 'C' class roads references.

[Lester Caine]

On 04/08/18 10:02, David Woolley wrote:

On 04/08/18 07:01, Philip Barnes wrote:
The renderer cannot know not to render refs on C roads in the UK, 
remember osm is an international database.


Telling a driver to turn left onto the C666 is confusing if there is 
no sign to back up that instruction.


Routing type renderers need to know that a road is in the UK and handle 
it accordingly, because a lot of tagging has to be interpreted in the 
context of national legislation.


And it would be nice if they also respected the national speed limits! 
Osmand needs every 'max speed' to get it to display 60 or 70 as 
appropriate :( And I WILL get around to adding a UK rendering of road 
colours sometime ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] 'C' class roads references.

[Lester Caine]

On 04/08/18 07:01, Philip Barnes wrote:

If you want to produce a render to display these admin references then you are 
welcome to do so.


We ideally need a proper UK rendering of data and this is another area 
where information IDEALLY needs to be selectable. Trying to make a 
single world wide rendering of the data is always going to fail given 
the volume of material that is now country specific. The 'C' and other 
paper references need to be attached to relevant way and it's somewhat 
academic how as I can give you many examples where the 'B' references 
are similarly not actually displayed on the ground! Should they be 
tagged using some 'hide' tag? 'ref' is the correct tag for the way's 
reference number ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] building=grandstand vs leisure=bleachers

[Lester Caine]

On 14/07/18 07:23, Tomasz Wójcik wrote:
Building=grandstand is not perfect for me, beacuse building=* tag 
suggest that is some kind of typical building (with walls, roof, etc.) 
and most of the OSM styles render building=grandstand like every other 
buildings, where you can go inside, which may be confusing with 
grandstands areas. On the other hand we have leisure=bleachers , when 
the "bleachers" word is propably used only in USA.


What do you think about it?
Many of these are a compromise, but I would expect more tags not less. 
The problem with these two are they span different 'domains' as a number 
of others do. A built structure is a 'building', and there are a range 
of structures covering seating, so grandstand, covered_seating, 
open_seating ... move the leisure tag to a more appropriate tag? In 
addition, many of these can well be temporary structures for a 
particular event but present for some time perhaps every year.


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] proposed mechanical edit - moving FIXME=* to fixme=*

[Lester Caine]

On 03/07/18 13:21, Dave F wrote:
Removes duplicated, reduces confusion, easier to search. A good Spring 
clean improves the database.


I really think this fear of bulk edits has gone too far.


I would probably ask just how many of the tags you think are duplicated?

The point here is that there is no NEED for this edit, and it basically 
does nothing to improve the database. It simply hides this block of tags 
within the later larger bulk of 'fixme', when as has been said, if these 
have been around for so long they should be addressed.


Miss-spelt tags being bulk edited is one thing, but 'FIXME' is clean and 
changing them just because you can adds nothing to the data. Get on an 
deal with them to remove them all together is the right tack ...


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] proposed mechanical edit - moving FIXME=* to fixme=*

[Lester Caine]

On 03/07/18 09:28, Frederik Ramm wrote:

On 02.07.2018 19:42, Mateusz Konieczny wrote:

It would make development of QA tools easier as authors would not need to
discover and implement support for this duplicated key.

I think the downsides of such a large mechanical edit far outweigh the
advantages.

Don't forget that new FIXMEs will continue to appear all the time.

Software should be able to deal with both.


I'm with you on this Frederik. The correct fix for a 'FIXME' tag is to 
deal with it or remove it completely if no longer valid, and adding 
extra change events to 'fixme' only gets in the way of that.


IF there is a general consensus that some tags are no longer acceptable, 
then the first step is to fix the API to prevent their use? Once the 
source of the problem is eliminated THEN address the historic data.


Is there any case for not enforcing lowercase only tags? The fact that 
'FIXME' and 'fixme' can exist on the same node just seems wrong in ANY case?


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] About OSM social implications and what can/should be displayed on the map (or not)

[Lester Caine]

On 29/06/18 16:27, Carlos Cámara wrote:
Second: The very foundations of OSM as a project are techno-political in 
terms that it was created to overcome the lack of certain geographical 
information about certain areas or topics. This is even more obvious in 
HOSM or the not-at-all-accidental use of open licenses from its very 
beginning.


Yes and No ... 'the map' is NOT the project ... the raw data is. I find 
it difficult to use the current style of the SAMPLE map provided simply 
because it gets the road colours wrong now. So I'm using a source of map 
tiles that use a more UK friendly colour set. The bottom line is that 
what is displayed on the map is already in conflict with many uses 
ignoring adding any additional censoring. What SHOULD be done is provide 
our own versions of the map for our own applications, as wikipedia is 
doing with names (although I can't see how to access them). Whether 
something has it's own icon is not a political decision - everything 
should have an icon - but the PRIORITY of displaying should be a 
non-political decision - not censorship!


Moving to a more interactive map would be a positive step, rather than 
the continual churn of 'views of what is important' on a single static 
map and I know the technology is there, just not the resources to 
generate it?


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] Toys R Us

[Lester Caine]

On 05/05/18 23:41, Rob Nickerson wrote:
If an old sign still exists then this should be mapped *as a sign* not 
as a shop.


With a number of other closures around here, premisses are remaining 
empty for a LONG time, and with no one taking over the buildings remain 
as they were, just not open. If I am using the map to navigate, and the 
place I want is 'around the back of X' then the building X is what I am 
looking for. UNTIL the building identity changes to some new use it 
should be mapped as it appears. If the signage is taken down then rather 
than 'shop-closed-ToyRUs' it should change to 'shop-closed' but I don't 
see much movement on signage being taken down on other closed 
businesses? So we maintain the accurate mapping ... and map what is seen.


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] UK Quarterly Project: Post Offices

[Lester Caine]

On 04/05/18 14:41, Steve Doerr wrote:

On 04/05/2018 12:52, Lester Caine wrote:

it's not helped when postoffice.co.uk don't list the independent post 
offices in there search results! According to them Broadway does not 
have a post office ;)


It comes up for me at Russell Square, Back Lane, Broadway, 
Worcestershire, WR12 7AP. I searched on that postcode. Or is there 
another Broadway?


OK is google that gets it wrong ;) 
https://www.google.com/search?q=post+office+near+me only shows the post 
office owned ones. But the information on the branch search - when you 
find it (needs the worcs) - is at odds with the times on the Budgen's 
website which I know are correct but the magic time one needs to know is 
5:15 as the latest time for collection today is not shown anywhere :) 
Only https://www.warnersbudgens.co.uk/post-offices/broadway.php shows 
the out of hours services ...


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] UK Quarterly Project: Post Offices

[Lester Caine]

On 04/05/18 12:28, Robert Whittaker (OSM lists) wrote:

Or do people think we should use amenity=post_office for them with
some other tagging used to differentiate things? If we did want to use
other tagging to differentiate, then operator=* wouldn't work, as most
Post Office branches are run by third parties. network=* or brand=*
could do, but it would be complicated to use either on objects which
are tagged with both amenity=post_office and e.g. shop=convenience,
since we wouldn't know which part the tags were referring to.


Our local post office is now situated in a local supermarket while the 
main postbox is still located outside it's previous home. Post Office 
hours are shorter than the opening for the shop although some services 
are available full time which adds to the fun tagging it. In addition 
two other local shops are drop-off points for other other carriers with 
one also a collection point for held deliveries. The published details 
for some of these service points is already wrong but trying to add a 
comprehensive set of tags covering everything is I think wishfull 
thinking? Especially when the shop handles several courier services? 
This is an area where secondary databases should be linked to provide 
the fine detail and just a generic tag with an ID to access that data. 
Trying to map all the secondary data is silly, but it's not helped when 
postoffice.co.uk don't list the independent post offices in there search 
results! According to them Broadway does not have a post office ;)


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [Talk-ca] Trans-Canada Highway research

[Andrew Lester]

While standardization may be nice, it often won't be possible even within a 
single country. As has already been discussed, there are differing conventions 
in different provinces, so please don't try to apply a single plan to all 
provinces. How the TCH is handled in OSM will vary depending on the province. 

For example, in BC (and some other western provinces), the TCH carries the 1 
ref. In some places where other ref'ed highways coincide with the TCH, the ref 
is recorded as "ref=1;19", for example. There are places within cities where 
the TCH runs on city roads with different names (e.g. Douglas Street in 
Victoria), so those ways are named with the local name and the TCH name is 
recorded in the alt_name or nat_name tag (a separate argument is which one of 
these to use). An alternate name should never be added to the primary name in 
brackets like proposed. That's exactly what the alt_name (and similar) tags are 
for. There are also many places where Trans-Canada Highway is the official 
local name of the road, like most of the highway in BC. 

As for the correct spelling of the TCH, I think it would be fairly 
uncontroversial to standardize the name to "Trans-Canada Highway" or "Route 
Transcanadienne" where it's appropriate to use the TCH name, because those are 
the official spellings. Any variants can be considered errors. 

As for varying highway classifications, this is correct and to be expected. 
Unlike the US interstate system, the Trans-Canada Highway network varies in 
construction and importance all across the country, so the classification can't 
be standardized to just motorway or trunk. There are sections where primary is 
the most appropriate, and possibly even secondary in some places. Just on 
Vancouver Island alone, the roads designated as the TCH vary from a six-lane 
motorway all the way down to a two-lane effectively-tertiary road. 

Since there will need to be a lot of local knowledge required for such a 
project, I strongly recommend that this project not be undertaken by Telenav. 
This is the kind of work that Canadians should be doing, being the most 
familiar with the on-the-ground situation which will dictate how the highway is 
handled in each province. The numerous past issues with Telenav's contributions 
is also a factor that can't be ignored. Does it really make sense for a team of 
Romanians with a history of questionable decisions to be making sweeping 
changes to the Canadian national highway network? At least they've brought a 
proposal to the community this time rather than just push forward with a faulty 
plan like they have in the past. I'm still cleaning up after previous Telenav 
projects in my area that added countless non-existent turn restrictions and 
names and also removed valid data. 

Andrew 
Victoria, BC, Canada 


From: "Olivia Robu - (p)"  
To: "talk-ca"  
Sent: Monday, March 26, 2018 4:20:16 AM 
Subject: [Talk-ca] Trans-Canada Highway research 



Hello, 

The Telenav Map team has done some research on the status of the ways and 
relations of Trans-Canada Highway. 

Here are some conclusions from this research: 

* The highway is formed from 30 routes; 
* Every route has different names for the name tag, such as: street names, 
other routes names or Trans-Canada highway name in different forms; 
* The issue above is repeating for the ref tag; 
* The name of Trans-Canada highway has more than one form (Trans-Canada 
Highway, TransCanada Highway, Trans Canada Highway, etc); 
* Another issue is the variety of names in other tags related to it (such 
as: name:en, name:fr, alt_name, alt_name:en, alt_name:fr, nat_name); 
* There are some routes that don’t have a route name only ref (5 routes); 
* There are some routes that overlap: 
* in Manitoba: - PTH 1 (MB Trans-Canada Highway) and Trans-Canada 
Highway (Super); 


- Yellowhead Highway and PTH 16 (MB Trans-Canada Highway); 



* in Alberta: Trans-Canada Highway (AB) and Trans-Canada Highway 
(Super); 
* in British Columbia: - Trans-Canada Highway (BC, Super) and 
Trans-Canada Highway; 


* About 90% of these routes are broken; * About 80% of these routes 
have highway value flip flop (motorway, trunk, primary); 




We propose to make some improvements to standardize all the routes. We would 
like to get your thoughts and feedback on the following questions: 

* What is the correct form for the name that appears in the way name tag? 
For example: “Highway 417” is part of Trans-Canada Highway and has the name 
value tag “Highway 417”. To resolve this issue, we would need to standardize 
the ways’ name tag for all the provinces. The question is, should we modify the 
way names in to “Trans-Canada Highway”, or should we insert the name 
“Trans-Canada Highway” at the end of the name, like this: “Highway 417 
(Trans-Canada Highway)”, or should we leave it like it is? 
* Another issue 

Re: [Talk-GB] Petrol stations again

[Lester Caine]

On 09/03/18 20:19, Philip Barnes wrote:

Leicester Forest East looks a bit confused, it is down to both modify a
Shell node and to add a BP node. It can't be both.

I will try to check what brand it really is.


It's a Welcome Break, so Shell ... at least it was last time I passed.

--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] Please do not re-use old node IDs

[Lester Caine]

On 06/03/18 10:26, Frederik Ramm wrote:

Long story short, please don't do it - let the API assign you new node
IDs to your stuff instead of building ingenious contraptions to recycle
old nodes.


The reality is they are not 'old nodes' simply nodes which are not 
currently visible. I think I know the answer, but should the API be able 
to accept these ID's anyway? In an ideal world, the previous now hidden 
data should perhaps be flagged when the ID is used?


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Lester Caine]

On 24/02/18 20:49, Martin Koppenhoefer wrote:

Every country may have different peculiarities, but the general concept is the 
same: a road usually restricted to motorized traffic, typically grade separated 
and distinct carriageways.

We’re normally using British English in tagging but this doesn’t mean we 
couldn’t map things that don’t occur in the UK or for what they don’t have a 
word.


I think the main problem is that there are well established guidelines 
for various areas on mapping data at both country and region level but 
in may cases even those rules do not harmonize. We need the several 
levels of highway that are currently accurately mapping UK roads, but 
other areas of the world do not need that degree of classifications ... 
so they just don't use the ones that are not appropriate ...


( And I am battling getting my computer working again as it was such as 
getting email replies properly handled on different lists :( )


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Lester Caine]

On 24/02/18 09:30, djakk djakk wrote:

There is 2 « independant » things in the debate :
1) trunk definition - what is a trunk, a motorway-like road - based on 
physical characteristics- or a super-primary road - based on the 
importance ?
Since the classification initiated from the UK, that is still the base 
and a motorway has restrictions that do not apply to a trunk route such 
as 'no learners'. In addition they were maintained 'nationally' while 
primary roads are a local responsibility. That was been muddied much as 
the idea that trunk routes are faster. For the UK the road structure is 
well defined and it would be nice to get back a rendering with the 
proper colours ( and a selection for that on OSMAND ) ...


2) wordwilde trunk definition ? - should we have the same definition all 
over the world of what is highway= trunk ? (value that are 
country-dependant are not that common, aren’t they ?)
Since there are no distinctions in many countries there is no need to 
include truck if there are no such roads in a country, and perhaps for 
'world wide' trunk gets rendered the same as motorway or primary? Only 
local rendering actually benefits from the distinction? Do any countries 
not have motorways at all? Certainly the current default rendering is 
useless for many of us anyway so we have to ue an alternate anyway ...


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] Errors in Street Names in Addresses

[Lester Caine]

On 01/02/18 08:58, Robert Whittaker (OSM lists) wrote:

On 31 January 2018 at 11:13, Will Phillips<wp4...@gmail.com>  wrote:

I favour using addr:parentstreet rather than addr:substreet for the
following reasons:

+1


Which also then needs addr:street ON the addr:parentstreet as using 
postal_code has the same problem of matching ... OR is that only to be 
used on the buildings ON the substreet ?


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] Errors in Street Names in Addresses

[Lester Caine]

On 31/01/18 09:07, Mark Goodge wrote:

On 27/01/2018 20:09, Robert Whittaker (OSM lists) wrote:


Secondly, some addresses contain two street names, a main
street and a so-called "dependent street". Apart from the historic
anomalies, a single postcode should only cover one main street, but
can include more than one dependent street.


These are actually quite common, and having had a look at the error list 
for my local area nearly all of them are due to this - the address is on 
  secondary street accessed from the main street with which it shares a 
postcode. Here's one, for example:


https://www.openstreetmap.org/way/304095650


(The tool will not see the
dependent streets as different if both streets are tagged, either as
addr:substreet and addr:street or as addr:street and
addr:parentstreet.) 


Which is the more correct usage here? Do we

a) tag the dependent street as the addr:street, and the main street as 
addr:parentstreet, or should we


b) (following Royal Mail practice as found in the PAF), tag the 
dependent street as a addr:substreet and the main street as addr:street?


My personal preference would be the latter, it's not only consistent 
with official addressing practice but it's also how most people perceive 
these kind of addresses as well. But, on the other hand, most map 
editors are likely to use addr:street for the dependent street, simply 
because the editor UI doesn't make it obvious that addr:substreet is a 
possibility. So it might be simpler to fix these by adding 
addr:parentstreet as necessary rather than trying to get everything 
pedantically correct.


I've the same problem on a number of cases and certainly 
addr:parentstreet is just wrong ... the sub street is actually part of 
the house detail rather than the street, so similar to 'Flat 1 Block of 
Flats' ' Street' but this still leaves the 'addr:street' or 
'postal_code' question for the tag on the primary street. Having SOME of 
these tagged 'addr:parentstreet' is simply wrong ...


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] Errors in Street Names in Addresses

[Lester Caine]

On 30/01/18 15:04, Robert Whittaker (OSM lists) wrote:

Sorry about that -- it was a bug in my code -- which I think I've
fixed now. Have another look at
http://robert.mathmos.net/osm/addresses/street-warnings/WR.html  --
there's a lot more moved to the highways section now.


That is looking a lot more sensible. On my todo list, only the entries 
on the highways section with different names need work. I am going to 
leave postcode on addr:postcode and I'll start working through the WR 
stuff with missing street names, but the other 'errors' look a lot 
easier to handle as they are just spelling and secondary street names. 
We just need to agree how to tag all the highway stuff to wipe them from 
the list?


I do appreciate the work you are doing ... I've been wasting more and 
more time on simply keeping machines working, with all the crap on 
windows machines being chased hard on the tail by similar ones on my 
main Linux machines. Having rolled back to SUSE LEAP42.3 on the main 
machine I've got a browser that works again with potlatch2 and a JOSM 
setup that is working, along with the main development platforms for the 
day job. PERHAPS now I can actually get some new work done in several 
areas ... I've even got all 4 screens running cleanly for the first time 
in years so I can keep multiple views open while cross checking things.


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] Errors in Street Names in Addresses

[Lester Caine]

On 30/01/18 10:14, Robert Whittaker (OSM lists) wrote:

(There weren't nearly as many objects in case 2 as I thought there
would be here based on people's comments, so it's possible I've messed
up the programming logic somewhere. If there are still any objects
with a highway=* tag listed in other sections, then please let me
know, and I'll see if I can fix the bug.)


http://www.openstreetmap.org/way/4298681 is now listed in 'highways with 
postcodes' for WR12 7EP, but my next road which is tagged the same way 
https://www.openstreetmap.org/way/4299405 is under 'Street Name 
Mismatches in Postcode Unit' but has the same name in both columns, so I 
don't see what the problem is ... A large number of WR12 7** postcodes 
are correct as far as MY checks show. WR12 7JJ, WR12 7PH, WR12 7PP ... 
WR12 7PJ has snagged a bus stop node ...


One source of questions is the addition of addr:postcode to bus stops. 
https://www.openstreetmap.org/node/799223204 for example seems just 
wrong as it's now where near the WR12 7HP road and a quick check on 
local bus routes shows none stopping there anyway ... AH looks like the 
bus stop is now in the wrong place ... buses go down WR12 7HP now. But 
you can see the problem that adding postcodes to objects that don't have 
postal addresses seems strange except if one is tagging for routing :(


Other nodes are also throwing up questions such as 
http://www.openstreetmap.org/node/3383359238 ...OK - WR14 3LT and WR14 
3LY are getting confused by the ' which is not on the PAF file or on the 
Worcestershire Hub listing ... but is on google maps :)


But I would repeat that while 'Code-Point Open' provides a list of valid 
postcodes, it can't be used to check the street names, so adding the 
postcode to the street seems to be the right thing to do. The only 
question is if t should be addr:postcode and combined with other addr: 
elements for 'place' or simply 'postal_code' ... I can accept the second 
if the guide is also to omit other addr: elements from the street 
tagging ... use of addr:place, addr:location and the like cries out for 
addr:postcode ... 'postal_code' pairs up with 'is_in' which is something 
else that does not work well?


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [Talk-GB] Help remembering how to ...

[Lester Caine]

On 29/01/18 21:22, Lester Caine wrote:

It has been a while and my notes and crib sheets seem to be messed up.

Have JOSM running with ImportImagePlugin and I have a tif file with a 28 
pixel per meter scale, and the lat and long for the top left corner, but 
I'm obviously not putting the right numbers in the world file which I 
have done in the past and fine tuned position once loaded so has 
something changed, or have I just got the wrong data. I'm fairly sure I 
also had a Linux program that helped me play with the values but having 
brain freeze at the moment ...


First problem solved ... it's PicLayer plugin ... and then I can tweak 
the config files ...


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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