Re: [OSM-talk] recommendation for JSON to CSV converter

[Colin Smale]

> On 28/02/2024 17:30 CET Martin Trautmann via talk  
> wrote:
> 
>  
> On 28.02.24 16:43, Mike Thompson wrote:
> > Hi Martin,
> > 
> > Could you provide some more detail on what specifically you are
> > attempting to achieve? Converting a geojson file of points to CSV is
> > pretty easy, but once you get to linestrings, multi-linestrings,
> > polygons, etc. it gets difficult because in those cases the geometry
> > objects have a variable number of components.  
> 
> Hi Mike,
> 
> what I need is
> 
> Strassenna;HsNr_Zus;StrSchlues
> Stinnesstr.;8;02968
> 
> ..which I could grep easily, but I would also need to know in which
> "Gemeinde" that is, including their "Amtlicher Gemeindeschlüssel (AGS)"

Have you looked at "jq"?
Some tips here:
https://qmacro.org/blog/posts/2022/05/19/json-object-values-into-csv-with-jq/
https://richrose.dev/posts/linux/jq/jq-json2csv/

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

Re: [OSM-talk] razed railways and other things that don't exist today

[Colin Smale]

 

> On 25/10/2022 19:18 CEST Brian M. Sperlongano  wrote:
>  
>  
>  
> On Tue, Oct 25, 2022 at 4:37 AM Frederik Ramm  mailto:frede...@remote.org> wrote:
> 
> > in the spirit of friendly collaboration I would say that a limited amount of
> > stuff-that-should-not-be-in-OSM can be *tolerated*. If someone does a
> > lot of good work for OSM otherwise and would really like to record an
> > ancient former railroad that ran through where their house now sits - I
> > shrug and let them do it.
> > 
>  
> In my experience, it is more often the opposite situation that happens.  A 
> mapper, unaware of the lengthy debates on the topic of former railroads, is 
> mapping her house and removes the bit of abandoned rail currently on the map 
> in that spot, assuming it is a data error or poor import.  After all. she's 
> quite aware that there is a house and not a railway at that location as she 
> has personally surveyed it.  Sometime later, an abandoned railway enthusiast 
> comes along and angrily harasses the mapper for removing the bit of railway 
> that quite rightly isn't there. It's been my experience that allowing 
> enthusiasts to map phantom railways causes far more grief and contention 
> between mappers than simply drawing a line and saying "we don't map things 
> that aren't there."
> 
I expect pages with "This page intentionally left blank" save quite a few calls 
to customer service. I.e. if you draw a line and label it somehow "this line 
should not be here" you might defuse the argument and to a point where 
live-and-let-live counts again. Putting an end-date on it might be a start.
 
Are underground pipelines and electricity transmission cables just as 
controversial? They are covered over, built on, and completely unobservable 
from the surface. They may also have been taken out of service many decades ago.
 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Doocracy | Re: Idea for improving mapping system

[Colin Smale]

On 2020-10-18 15:04, Simon Poole wrote:

> Am 18.10.2020 um 11:07 schrieb Rory McCann: 
> 
>> Like mnany things in OSM, the reason it hasn't been done is because no-one 
>> has actually done it yet. It looks like other people find your idea of 
>> "levels" and "badges" interesting, so you should try attempt it yourself.
> 
> Like many things in OSM, the reason that it isn't being done, is because it 
> has been tried and has failed. It looks like that other people don't find the 
> idea of "levels" and "badges" interesting, so you shouldn't attempt it again.

...unless either the proposal, or the circumstances, have changed in
some significant way, or unless a substantial period of time has passed.
Never say never.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Osmf-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Colin Smale]

On 2020-08-06 11:47, Martin Koppenhoefer wrote:

> Am Do., 6. Aug. 2020 um 11:26 Uhr schrieb Lukasz Kruk 
> : 
> 
>> I'm not sure what rules govern this: "Londn" does find the capital of the 
>> UK, but "Warszaw" does not find the capital of Poland...?), which is only a 
>> little inconvenient when compared to the second-best online map.
> 
> this is because Londn is apparently the name in West Flemish 
> Londn (name:vls) 
> https://nominatim.openstreetmap.org/ui/details.html?osmtype=R&osmid=65606

And which language is "Warszaw" supposed to be? It doesn't seem to match
any of the name strings in OSM. 
https://www.openstreetmap.org/relation/336074___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Colin Smale]

On 2020-08-02 16:41, Sören Reinecke via talk wrote:

> Also Linux is the future. Every application that cannot run under Linux will 
> fail in the long run. Remember that Windows shouldn't be the main target 
> platform anymore because it is dying and the society is to blame that they 
> don't get it.

Linux is a big part of the future for server platforms, but in its pure
form it has lost the battle for the desktop. Windows and MacOS as
platforms capable of enterprise-level management are not going anywhere
soon. Don't ignore ChromeOS and Android for local "desktops" either -
both are Linux-based of course. 

The biggest dependencies should not be the OS but the runtime
frameworks. This world used to be java-based; these days .NET Core is a
viable competitor, as is Node.js. As a server-side application supplier,
if your product doesn't run in a container, it doesn't exist. Containers
basically mean Linux and Windows. Actual host OS is irrelevant - only
the container environment matters.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?

[Colin Smale]

On 2020-06-12 13:00, Frederik Ramm wrote:

> Hi,
> 
> I wonder if it would be feasible or desirable for editors to warn users
> if they are at risk of creating country/world-spanning changesets.
> Something like "you have unsaved edits more than 500km away from where
> you are editing at the moment, please upload those before you continue"
> or so.
> 
> World-spanning changesets are a constant source of irritation, and very
> rarely intentional.

But sometimes they are intentional, so they should not be prevented
entirely, but possibly just challenged. Admin boundaries may need to be
exempted? 

I am not sure how the bounding box for the changeset is calculated at
present, but for these purposes it should possibly be limited to the
nodes that have changed, and not automatically expanded to the entire
way or relation that the change impacts. Moving one node on a country
boundary should not classify the changeset as covering the whole
country. 

There are probably farms in Texas bigger than Luxembourg... Where do you
draw the line?___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Should we map things that do not exist?

[Colin Smale]

On 2020-05-25 18:52, Mateusz Konieczny wrote:

> Even if "Nothing is "approved"" is true it does not mean that nothing is 
> forbidden. 
> Can you name one tag that is "forbidden"? Does that mean a standing 
> instruction to all mappers to remove it whenever it is found, or a license to 
> do a seek-and-destroy across the whole database? Or does "forbidden" not 
> quite mean "may not appear in OSM"? "Frowned upon" possibly.

I would say that 

"Does that mean a standing instruction to all mappers to remove it
whenever it is found, 
or a license to do a seek-and-destroy across the whole database?" 

applies to several things (listed below). 

>> Is there any case of a whole class of objects being removed from OSM on the 
>> grounds  
>> that they "do not belong"? Who would burn their fingers on that? 
>> Depends on what you mean by "whole class of objects".
> 
> Class, category, whatever... A subset of the objects in the OSM data with 
> common characteristics. 
> 
>> If we are looking to set a precedent for that it would probably be wiser to 
>> pick on a less controversial and emotive subject. 
>> 
>> We have precedent that entire classes and types of things are 
>> out of scope.
> 
> Where is that written down? What classes and types of things have been 
> declared out of scope?

For example things that I immediately remember 

- fictional objects 
- blatantly subjective things like reviews, ratings 
- mapping of private objects (location of my bed) 
- mapping of moving objects (location of myself or a moving ship or
plane) 
- completely gone objects (for railways the question is when railway is
fully gone) 
- personal detail (ties into subjective ones) like "my favorite trees",
or "towns I visited" 
- objects on Moon/Mars and other locations outside Earth 

Objects with these characteristics cannot be (easily) identified in the
data - they would need a human to judge on a case-by-case basis (except
for the extra-terrestrial things, but you might have trouble defining
their location in terms of WGS84 lat/lon anyway...) 

Subjective data is by definition not independently verifiable, so that
can go. Ratings are sometimes awarded by a recognised body (rather than
by customers), and those ratings would IMHO qualify as independently
verifiable.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Should we map things that do not exist?

[Colin Smale]

On 2020-05-25 17:08, Mateusz Konieczny via talk wrote:

> May 25, 2020, 16:48 by colin.sm...@xs4all.nl: 
> 
> On 2020-05-25 16:20, Jack Armstrong wrote: 
> 
> Why are railways given a special status? 
> 
> Nobody gives anything a status in OSM. Nothing is "approved" so nothing is 
> "forbidden" either.

It is not really accurate - there is plenty of forbidden things (like
running 
imports without discussion, we have tags that are silently removed by 
editors like iD and JOSM). 
Doing imports without discussion more about the process, and less about
the details of the result. An import can be declared "bad" for many
reasons. 

If iD and JOSM remove certain tags when they are encountered, that is
different from removing whole objects. 

> We have voted on tags that are described as "approved". 
> 
> Even if "Nothing is "approved"" is true it does not mean that nothing is 
> forbidden.

Can you name one tag that is "forbidden"? Does that mean a standing
instruction to all mappers to remove it whenever it is found, or a
license to do a seek-and-destroy across the whole database? Or does
"forbidden" not quite mean "may not appear in OSM"? "Frowned upon"
possibly. 

> Is there any case of a whole class of objects being removed from OSM on the 
> grounds  
> that they "do not belong"? Who would burn their fingers on that? 
> Depends on what you mean by "whole class of objects".

Class, category, whatever... A subset of the objects in the OSM data
with common characteristics. 

> If we are looking to set a precedent for that it would probably be wiser to 
> pick on a less controversial and emotive subject. 
> 
> We have precedent that entire classes and types of things are 
> out of scope.

Where is that written down? What classes and types of things have been
declared out of scope? Any record of a transparent process that led to
that?___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Should we map things that do not exist?

[Colin Smale]

On 2020-05-25 16:20, Jack Armstrong wrote:

> Why are railways given a special status?

Nobody gives anything a status in OSM. Nothing is "approved" so nothing
is "forbidden" either. It is either used, or it is not used. It is not
even "forbidden" to use tags that someone has declared "deprecated". 

Is there any case of a whole class of objects being removed from OSM on
the grounds that they "do not belong"? Who would burn their fingers on
that? 

If we are looking to set a precedent for that it would probably be wiser
to pick on a less controversial and emotive subject.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Colin Smale]

On 2020-05-25 10:27, Florian Lohoff wrote:

> A small and very vocal part of the German community proposes to tag
> EVERY driveway - no matter if it has a gate or sign with access=private.
> Somebody slipped stuff into the German access=private page which i
> removed a while back as it had no consensus. Still some continue with
> this practice and for me they break the delivery use-case and a lot of
> other stuff (You cant to blind navigation to the front door as private
> has to be honored)
> 
> You cant tell whether this access=private is okay to break, and the
> other not.

"private" is not the same as "no". It simply means that the owner has
the right to decide who to admit, and the default is "no access" unless
you have explicit or implicit permission from the owner. 

With respect to private driveways, they are simply private. The owner
will tolerate friends and neighbours, postmen, delivery drivers etc
coming to the door - you could say they have implicit permission. A
random person however has no implicit permission and must keep out. 

In Germany it sounds like it is the same as it is here in the
Netherlands. If you don't put up a sign saying "keep out" or equivalent,
no actual offence is committed by passing the sign onto your land.
However you, as the land owner, have the sole right to erect such a sign
at your discretion and to make the rules as you see fit. 

There is also the category "access=permissive" which is in the middle.
You have no statutory right to access the land, however the owner has
clearly decided to allow the public access (i.e. everybody has implicit
permission). The owner can (in theory at least) rescind that implied
easement at any time or otherwise restrict access.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Colin Smale]

On 2020-05-25 00:16, Florian Lohoff wrote:

> On Sun, May 24, 2020 at 11:54:02PM +0200, Colin Smale wrote: On 2020-05-24 
> 23:16, Mateusz Konieczny via talk wrote:
> 
> Can you give an example of such untaggable restriction? 
> In the UK there are many small roads signed as "Unsuitable for HGVs."
> Legally you are allowed to drive your 44T truck down there, but you will
> almost certainly get stuck. How do we tell the router?

width? maxwidth? 

It needs to be a physical attribute, not a purely legal one. It could be
a combination of road width and bends, or undulations giving a risk of
grounding. For the former, the router would need accurate geometry info
(centre line and width) which is often not present or not reliable in
OSM. For the latter, do we have anything for "risk of grounding due to
dips and humps"? 

> It a different attribute than legalese which makes it unsuitable - so
> tag it appropriate.
> 
> 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". 
> Discussion here shows the  
> http://www.trucknetuk.com/phpBB/viewtopic.php?f=5&t=140446
> Thats a technical difficulty in the OSM Data model which may fill pages.
> 
> At least in Germany a restriction sign is not a "linear restriction"
> e.g. is restricting the whole way. Instead you may not traverse the
> point of the sign. We are currently unable to put this into OSM.
> 
> A workaround is to put 2 short oneways on top of each other - one of
> them carrying the restriction - which is in itself a pretty ugly
> solution - and - this does not work for destination.
> 
> There are other problems. A destination technically is currently solved
> by increasing the "cost" in the routing graph. So for example for
> every meter on a destination road you may travel 20m on others. Which
> most of the time works pretty well in avoiding the destination roads.
> It has pretty bad side effects which causes the router to try to send
> you out of the destination area with the shortest way even producing
> very long diverts around.

You talk as if all routers are the same I accept that such
heuristics are inevitable to choose between multiple possibilities, but
proposing a route that would actually be considered illegal should not
ever happen (subject to data currency considerations). 

But still, access=destination does not permit the router to apply
different penalties to the two cases I mentioned. 

> Legally this is broken. Legally you may not enter the zone when
> your destination is not within that zone and there nothing like a 
> distance based penalty within that area.
> 
> So yes - there is a problem - But not within tagging. Its something
> routers need to solve.

Routers cannot work alone, they have to work together with the tagging.
It's not fair to claim it's all their problem. If the tagging does not
represent the nuances required, the router should not be expected to
just guess (at least where the difference is between legal and illegal).___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Colin Smale]

On 2020-05-24 23:16, Mateusz Konieczny via talk wrote:

> Can you give an example of such untaggable restriction?

In the UK there are many small roads signed as "Unsuitable for HGVs."
Legally you are allowed to drive your 44T truck down there, but you will
almost certainly get stuck. How do we tell the router? 

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". 
Discussion here shows the  
http://www.trucknetuk.com/phpBB/viewtopic.php?f=5&t=140446 

And then there are all the subtle differences in the semantics of the
vehicle classes, but that's a whole different can of worms...___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Colin Smale]

On 2020-05-24 20:47, Florian Lohoff wrote:

> - The "Ground truth" we tag restrictions only when visibly assigned and
> verifyable.

It is sufficient to say "verifiable". It does not always need to be
evidenced by a visible sign - as long as another independent mapper
could (easily) verify its truth. The fact that (in many countries) speed
limits and parking rules change when you enter a settlement means that
these attributes are verifiable without there needing to be an explicit
sign. 

> So - people try to overload the meaning of access=private
> with something more like ownership=private.

Access=private always means you have no "right" of access, and must keep
out unless you have permission from the appropriate authority (be that
the owner of a driveway or the operator of a nuclear power station).
That permission can be explicit (a permit or invitation) or implicit
(delivery drivers etc). Routers frequently apply different rules for the
first and last segments of a route, blocking routing over "private"
roads in the body of the route but not hesitating to use them if they
are the only way to access the start and destination locations.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Quality and the Openstreetmap value chain

[Colin Smale]

On 2020-05-12 15:28, Jean-Marc Liotier wrote:

> On 5/12/20 2:52 PM, Colin Smale wrote: 
> 
>> As you and many others frequently remind us: OSM is first and foremost about 
>> the data and not any specific use-case or rendering thereof.
> Yes - but a data model is not a neutral representation of reality: it is a 
> projection through a use-case, mapping reality to a construct fit for 
> specific purposes. In the relational database world, we cannot produce a 
> satisfactory schema without knowledge of what sort of queries are intended. 
> Flattening the highly dimensional reality into any data model involves such 
> choices. Closer to the daily preoccupations of Openstreetmap, even lists of 
> attribute values are reductionist and finding the appropriate tradeoff cannot 
> be achieved isolatedly: it requires input from those who will deal with the 
> consequences of the choices - the data-consuming users.

Absolutely, well put. Any kind of modelling requires reductions of
complexity, trade-offs and compromises. Which nuances are we going to
include, and which are we going to consciously choose to leave out? If
we don't leave anything out, we have not modelled reality, we have
duplicated it. 

The role I expect of the data consumers is to articulate how they would
like to view the data (including what attributes they are expecting),
and not to dictate how that data is stored/represented internally.
Cartography, geography, statistics etc are very different skills to data
modelling and database design.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Quality and the Openstreetmap value chain

[Colin Smale]

On 2020-05-12 14:06, Frederik Ramm wrote:

> Colin,
> 
> you're lumping in a few different things together I think.
> 
> The scarce resource in this project are still mappers, not consumers.
> The mappers certainly want to make a good and usable map; but if you are
> faced with a choice of either making mapping more difficult or making
> using more difficult, I would still argue for ease of mapping any time -
> especially as, for reasons of diversity, we're trying to extend the
> "long tail" of mappers who might not be willing and able to learn the
> ins and outs of public transport relation mapping.
> 
> So yes, let's give mappers the tools they need and let us have a
> dialogue with users about what they find useful, but if anything the
> users want means more complexity for mappers, I'm skeptical.

Thanks for the reply Frederik. It can't be impossible to have a
well-engineered internal setup, combined with a user-friendly external
interface. I.e., do the Right Thing in terms of data structures, tagging
models etc etc and present that to the user (through editors, primarily)
in a user-friendly way. I know it can be done, I have been doing just
that for 30 years. 

But it does require a level of meta-modelling. Real-world objects
(recognisable to mappers) need to be mapped onto internal concepts. At
present we have only nodes, ways and relations. Let's expand that
upwards to include simple polygons, complex polygons, fuzzy areas,
polylines etc (curved lines anyone?) Multipolygons and their alter ego
boundary relations are a step in the right direction, but why is a
boundary relation not simply defined as a "subclass" of a multipolygon
for example? 

And then a layer of high-level "constraints" such as coastline needing
to go anticlockwise. Is a relation an ordered list or not? The
documentation says it is, but why dp editors not make it very easy to
sort/re-order the members, or do it automatically? 

Next level would involve tagging: for each object type, which fields are
mandatory, recommended, optional, prohibited? What about regional
applicability? What is mandatory in one place may be optional somewhere
else. 

Editors can be coded to know about the metamodel, and then the
constraints; a config file (JSON, XML, whatever) can provide the tagging
schemas for the individual object classes. So we are not accused of
imposing stuff from above: let's merge in an unmanaged config file on
top of that so users can have their pet tags. 

As you and many others frequently remind us: OSM is first and foremost
about the data and not any specific use-case or rendering thereof. We
should take care to follow our own advice and nurture the data
(quality), while at the same time not being afraid to revisit the data
model and/or underlying metamodel. 

The community model of peers, with (by design) no real governance, has
led to a lot of frustration, wheelspin and stagnation when it comes to
making real progress on many fronts. We need to work on defining what we
mean by "data quality", making it objectively measurable (if you can't
measure it, you can't manage it), and taking steps to improve it. But
any definition of quality depends on articulating what is
good/right/expected vs bad/wrong/unexpected, and this is where we are
far too timid!___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Quality and the Openstreetmap value chain

[Colin Smale]

On 2020-05-12 12:34, Jean-Marc Liotier wrote:

> On 5/12/20 11:42 AM, Richard Fairhurst wrote: 
> 
>> I love the fact that we are now 50 messages into discussing, for the second
>> time, a change that would be made ostensibly for the benefit of data
>> consumers, and yet no one has asked any actual data consumers.
> 
> Yes. Users are the ultimate measure of quality, yet they are most often 
> absent from our discussions. Our history explains why: in the beginning, we 
> had a blank map, which we set upon filling with whatever we could, to get the 
> stone soup started. There were no consumers at all - so naturally our 
> universe was supply-side entirely: the availability of data inspired usage, 
> which came second. Nowadays, Openstreetmap is used - let's take advantage of 
> that to improve ! Looking at the world and thinking about how we should model 
> it should be done with an understanding of how users want it. This is 
> difficult when we have few users around and very little feedback from 
> downstream. So, if one has opportunities to bring that to our knowledge, 
> please do: it is valuable information to the Openstreetmap project, 
> information without which we cannot allocate our efforts optimally.

+1000 

If I had a «currency unit» for every time "ease of mapping" has trumped
"quality and usability of data" I would be pretty rich now. We have
always shied away from anything that would define data quality, as such
discussions inevitably involve the definition of "good" and "bad", and
"right" and "wrong". These discussions get killed stone dead as soon as
someone says "we can't change the data", "it would be too difficult for
mappers to understand", "applications expect the old way" etc.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[Colin Smale]

"unmaintained"? 

On 17 March 2020 10:52:39 CET, Warin <61sundow...@gmail.com> wrote:
>On 17/3/20 8:22 pm, Marc M. wrote:
>> Hello Joseph,
>>
>> it may give the impression that this is the way it should be done.
>> I agree to identify these "Noise" or poor quality tags, but with a
>> keyword to show that it's a problem. e.g. status=bad, disputed,
>error, ...
>> it would be necessary to find a word that is not as strong as error,
>> but which nevertheless clearly indicates that this is not an example
>to
>> follow.
>>
>
>Agree with both.
>
>Possible values?
>
>obsolete
>
>abandoned
>
>discarded
>
>
>
>archaic
>
>passe
>
>stale
>
>
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Colin Smale]

On 2020-02-14 10:18, Martin Koppenhoefer wrote:

> Am Do., 13. Feb. 2020 um 08:41 Uhr schrieb Colin Smale 
> : 
> Locations are stored in OSM as pairs of {lat,lon} and I assume these are both 
> 64-bit floats in the database. 
> 
> AFAIK they are stored as integers (shifting the decimals)
> 
> If so then then my comments about preserving precision still apply to all 
> "client" software and I bet the majority uses float. Then an innocent update 
> to a tag on a node can end up unintentionally moving the location slightly, 
> losing precision.

My comment about precision lost through conversion was not about missing
floating point digits, but about conversions from one CRS to another,
where you may need additional (proprietary) grid parameters to do a high
precision conversion. 

Yes I realise that but attention must be paid to all possible sources of
precision leakage. 

What use would proprietary parameters be? If they were used, are
relevant and kept private, this would impede the consumption of the data
by any clients. All GIS files must include, by value or by reference,
the relevant CRS, otherwise the contents can not be interpreted
properly, can they? Or are you thinking of the situation in China where
they have a state-controlled/licenced transformation?___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Colin Smale]

On 2020-02-13 00:15, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> Il giorno 13 feb 2020, alle ore 00:05, Colin Smale  
>> ha scritto:
>> 
>> Locations are stored in OSM as pairs of {lat,lon} and I assume these are 
>> both 64-bit floats in the database.
> 
> AFAIK they are stored as integers (shifting the decimals)

If so then then my comments about preserving precision still apply to
all "client" software and I bet the majority uses float. Then an
innocent update to a tag on a node can end up unintentionally moving the
location slightly, losing precision.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Colin Smale]

On 2020-02-12 23:34, Martin Koppenhoefer wrote:

> sent from a phone
> 
> Il giorno 12 feb 2020, alle ore 14:06, Colin Smale  ha 
> scritto:
> 
> Exactly this. A hobbyist or volunteer CAN verify an admin boundary (where it 
> is available as open data) - it is independently verifiable. It is 
> objectively of better quality than an OTG observation with a phone.
> 
> this will obviously depend on the individual case, but in some instances in 
> Europe I have seen the published open data boundaries were simplified 
> geometries. Just because the original datum was precisely acquired doesn't 
> necessarily imply that the published open data (often derivative data) is 
> super accurate as well (our own errors in the transformation of the data 
> during the import aside).

Good point about the simplification. If they do that by Douglas Peuker
then no points will be moved, but some points can be deleted. So any
points that make it through to the simplified data are accurate and
actually appear in the input. If the boundary, road or whatever is
actually curved, then we can subjectively improve on the published data
by inserting additional points, but we should use the accurate points as
a frame of reference and *leave them alone*. They are most likely to be
the very best data we can get our hands on, even if they are not 100%. 

Concerning data quality and its definition: 
Locations are stored in OSM as pairs of {lat,lon} and I assume these are
both 64-bit floats in the database. Any processing that we do on any
location should be done so as to minimise the error, so the
transformation parameters should be as accurate as possible and all
operations should be done at maximum precision - 64-bit floats ("double
precision" for the old guard) or, even better, 128-bit. When processing
this kind of data you need to be aware of these things, and principles
like these should also be considered "best practices". Results from
higher-precision inputs using higher-precision operations can be
considered to be *of a higher quality* than when a lower precision is
used. And when we "export" the data by translating the binary
representation to text (including XML), that should also be at a
sufficiently high precision, such that re-importing the data would lead
to the same binary representation. Every time data is loaded into an
editor, it is translated to a string, and when it is stored, it
translated back. This process must not lead to a loss of data precision!___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Colin Smale]

On 2020-02-12 10:42, Frederik Ramm wrote:

> Hi,
> 
> On 2020-02-12 10:28, Colin Smale wrote: 
> 
>> Where a boundary coincides with the centre line of
>> a road for example, and there is a discrepancy in OSM between the
>> locations of the two, there should be a recognition that the
>> professionally surveyed locations are more likely to be correct
> 
> I disagree.
> 
> What you are requesting here is that we blindly defer to authorities. "I
> cannot verify this - but a professional surveyor with his $10k equipment
> claims it is so - hence I guess I have to believe it."

Indeed, that is exactly what I am suggesting (without the "blindly"
bit). You can verify it, just not there and then with your cheap GPS.
OSM is built on trust, not mistrust. 

> I think this is not how OpenStreetMap should be operating. I can see how
> to a professional surveyor the idea must be painful that someone comes
> along with their rubbish equipment and makes a change, but we *are* a
> project of hobbyists and volunteers, and something that a hobbyist and
> volunteer cannot verify ("don't touch this unless you invest $10k in
> equipment first!!!") should not be in OSM, and we should not worship
> precision that we cannot create ourselves.

Exactly this. A hobbyist or volunteer CAN verify an admin boundary
(where it is available as open data) - it is independently verifiable.
It is objectively of better quality than an OTG observation with a
phone. 

The professional surveyor probably couldn't care less. I am thinking of
our downstream consumers.  Sounds a bit like Brexit... 

But some awareness amongst these hobbyists that some sources are better
than others, and their own measurements, even if they are more recent
than the contents of OSM, are not necessarily better, would surely not
be a bad thing.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Colin Smale]

On 2020-02-12 09:28, Martin Koppenhoefer wrote:

> I believe it is a misconception to think it must be "visible" on the ground, 
> rather it must be determinable on the ground / "in loco". There might well be 
> nothing to "see", but you could still check on the ground, by talking to the 
> local people, how to map something (particularly, how to call it). 
> 
>> Start with "If A, then B" where A is "it is on the ground" and B is "you may 
>> map it."  Now, try the contrapositive "If not B, then not A" (in logic 
>> notation:  ¬B -> ¬A).
> 
> this is not how complex situations work. "If its black it is not colored" 
> does not mean that if its not colored it must be black (could be white, gray, 
> etc.).

 And this is why we should not try to map a continuum of possibilities
onto a binary model. The OTG rule/guideline needs to accommodate these
shades of grey. A rule that leads to so much discussion and so many
exceptions is clearly not a good rule in its current form. Lets do some
process improvement here! 

I want to come back to a point I made a few days ago as well, concerning
location accuracy. If a point (possibly on an admin boundary) is
imported into OSM from a source which has used cm-level surveying
equipment, it is nothing short of WRONG if Joe Bloggs comes along with
his $100 smartphone and moves that point based on a 3-satellite 2D GPS
fix with a 100m GDOP. Where a boundary coincides with the centre line of
a road for example, and there is a discrepancy in OSM between the
locations of the two, there should be a recognition that the
professionally surveyed locations are more likely to be correct - so in
this example the highway should be moved to fit the boundary, and not
the other way around! This professional data provides an extremely
important collection of reference points, to which other data should be
aligned - just like the trig points of older survey systems. OTG IS NOT
ALWAYS BETTER! 

Elevations suffer from the same issues - except that the accuracy from
GPS is even worse. Don't get me started on the differing definitions of
"sea level" leading to meaningless elevations in OSM (because they don't
specify to which datum they are relative).___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Colin Smale]

On 2020-02-09 04:26, Joseph Eisenberg wrote:

>> Re: "on a government map, by legal / statutory decree, from data 
>> authoritatively published on a website"
> 
> These examples are not "good practice" sources for openstreetmap.
> While many mappers import data from such sources, there is no "value
> added" in the case that mappers are unable to confirm if the
> government or "authoritative" data is accurate or inaccurate. Since
> the data in Openstreetmap can be changed at any time, and often by
> mistakes caused by new mappers, the authoritative database or source
> will always be better for database users to consult directly, unless
> openstreetmap can improve the originally imported data by checking it
> against reality.

I beg to differ. Importing positions of accurately and authoritatively
surveyed objects gives us calibration points for our more manual work.
We are all warned about distortions and offsets in aerial imagery, and
99% of our on-the-ground mappers will be using consumer-grade GPS. If
the location of an admin boundary has been surveyed to centimetre
accuracy as lat X / lon Y, the presence of this in the OSM database,
plus an indication of its authoritative source, gives an invaluable
frame of reference. If Joe Bloggs comes along with his smartphone and
locates it at X+dX,Y+dY he needs to understand that it is he who has the
inferior data, and he should refrain from "improving" OSM by changing
the location of the boundary. If other objects like rivers, highways etc
should probably coincide with the admin boundary but don't, Joe Bloggs
needs to consider that the professionally surveyed data is more likely
to be correct before moving the admin boundary in OSM to fit his
imperfect data. 

Besides, OSM strives not only to be "complete" but also "useful". If
imports can increase the usefulness of OSM, it is likely to positively
impact its adoption. So what's not to like? 

A subject often ignored in OSM is defining what me mean by "data
quality." Quality is always relative to some definition of perfection.
Is a point entered by an "OTG mapper" with a smartphone, of higher
quality than a definitive, authoritative survey? 

> Remember, this is the "good practice" page we are talking about
> editing, not the "how things really are done" page: we want to focuse
> on the "Gold Standard", best practices.

Irrespective of the discussion above, Best Practises and Gold Standards
can often usefully be illustrated by negative examples. Standards have
quality too! A good standard will be unambiguous; one that is vague and
open to a lot of interpretation is not a good standard.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Colin Smale]

On 2020-02-08 18:03, stevea wrote:

> See, "the on the ground rule," to the best of my ability to determine it (an 
> exception is your opinion as you explicitly express here, and that's part of 
> the problem with it), isn't clearly defined and it needs the elasticity of 
> such ad hoc exceptions.  It doesn't say (explicitly, anywhere, except in your 
> exception) "we ask people there and look at books, other maps, Wikipedia, 
> travel books, organizations...if the name is used in reality."  You do (here, 
> as an "exception," by way of clarifying your understanding of OTG) but if all 
> of that is true, OSM should say so:  formally and as fully as possible.

The most important aspect of the "on the ground" rule is that things are
independently verifiable, i.e. given the evidence, anybody would come to
the same conclusion. Physical evidence is obviously very useful - for
example, either a highway is present, or it is not. But other sources,
provided they are freely accessible, can also provide facts that are
sufficiently verifiable. In the case of the US-CA border, I guess the
treaty or whatever is publicly accessible, so there can be no arguments
about where the border is in a legal sense. Of course not all boundaries
are fully specified in treaties, but I suspect this one is. 

So I suggest the "On The Ground" rule should be replaced by a
requirement for independent verifiability; our traditional definition of
OTG is sufficient but not necessary for compliance. 

Independent viability means (to me) a random member of the public, with
no special privileges, and without payment, and at any time, should be
able to "consult the source".___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Crimea situation - on the ground

[Colin Smale]

On 2020-02-08 11:48, Rory McCann wrote:

> It is true that government A might have one opinion, and government B might 
> have another, and Provisional Autonomous Republic of C might have another 
> opinion.
> 
> But there can be another way. We go there, and we see what nearly everyone 
> there calls it. We look at the words on the signs. We look at the name of the 
> organisations based there ("Transport for London"). We walk down the street 
> and ask 100 people what the name of this city is. We listen into 
> conversations there, and see if there's a majority name that people use when 
> they talk to each other about the city
> 
> And the answer to that is "London".
> 
> In OSM, we could tag that "the opinion of the UK government is that this city 
> is called London", and "the opinion of the French government is that this 
> this city is called Londres", and "the commonly used name for this city by 
> the vast majority of people who live there is London".
> 
> We should map the third option with the `name` tag.

Absolutely. But we should document our sources! Basic rule of research.
And if we choose to promote one alternative above the others, we are
skating on thin ice. Have we actually asked the people of Crimea
first-hand what they think? No=>it's someones opinion. Can we base our
choice on someone else's research? Which research is that? No=>it's
someone's opinion. Unless we can point to it being "in someone else's
opinion", we must take responsibility for our own conclusions. If that's
too hard, better to not have an opinion i.e. don't promote anything as
"more equal than others".___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Crimea situation - on the ground

[Colin Smale]

Many things we think of as "facts" are in fact somewhat subjective.
Things have a name or some attribute "according to" some authority.
London "is not" London, it is "called" London according to local people,
government etc. But the same place is "called" Londres, according to a
different authority, namely French-speakers; both points of view are
equally valid, but only within their intended context. 

In the case of Crimea, two different authorities have different views of
the jurisdiction to which it belongs. That is a fact, that we can safely
map. We can represent the border in one place "according to Russia" and
in another place "according to Ukraine" without taking sides. It is then
down to the renderer/consumer which source is preferred. If we don't
stop taking sides, well, we are taking sides - whatever our arguments to
support our choice. We will never "win" that one. 

I am applying a bit of data management here; every data item should have
a provenance, value domain, validity period etc. The "truth" is always
only relative to a particular frame of reference.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Old maps from Royal Collection UK

[Colin Smale]

On 2020-02-06 21:10, Andy Mabbett wrote:

> The UK's Royal Collection [1 [1]] have placed online [2 [2]] George III's
> collection of military maps which, they say:
> 
> comprises some 3,000 maps, views and prints
> ranging from the disposition of Charles V's armies
> at Vienna in 1532 to the Battle of Waterloo (1815).
> 
> I'm sure these will be of interest to many OSM mappers.
> 
> Remarkably, though, they are claiming copyright over these maps.

As I read it, they are claiming copyright in the images on the website,
which is probably fair enough. I cannot see where they claim copyright
in the maps themselves. But they do have ownership on their side; can
they be forced to make the original maps available for someone else to
photograph/scan? 
  

Links:
--
[1] https://en.wikipedia.org/wiki/Royal_Collection
[2] https://militarymaps.rct.uk/___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] weeklyOSM #497 2020-01-21-2020-01-27

[Colin Smale]

On 2020-02-04 13:36, Frederik Ramm wrote:

> Hi,
> 
> On 04.02.20 13:22, Colin Smale wrote: 
> 
>> Correct me if I am wrong, but I don't remember ever seeing
>> regional full history files.
> 
> The Geofabrik download server has full history files for every region it
> offers. Unlike the non-history extracts. these files are only available
> for users who log in with their OSM user name.

Aah, thanks Frederik, I didn't know about this. But the text on the site
seems to imply that it is only for "internal use" and I cannot use this
data for a public service, e.g. a website to animate changes in admin
boundaries. Can I get round that by cleaning out certain data? 

> that will be millions of API calls to get the full history
> of every node, way and relation involved. If it has to be, then it has
> to be.
> Famous last words before being blocked on the API ;)

At least I would only have to do it once, throttle the rate and leave it
running for a few days, and then keep it updated with the periodical
diffs.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] weeklyOSM #497 2020-01-21-2020-01-27

[Colin Smale]

I wonder how many users actually need a planet-wide planet file. Surely
there are loads of cases where a regional extract would suffice for the
use case in hand. How about encouraging people to consider using a
regional download? 

Something else, only slightly off-topic: I have often had ideas in my
head about looking at the dynamics of particular bits of data - i.e. OSM
histories. Correct me if I am wrong, but I don't remember ever seeing
regional full history files. I think there is a download available for
the entire planet with full history, but that is going to be a monster
and a real challenge to keep up-to-date. But it's the only way to get
historical data, except through the API. If I want to trace for example
the history of changes to county boundaries in the UK, or the alignment
of motorways, that will be millions of API calls to get the full history
of every node, way and relation involved. If it has to be, then it has
to be.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Metropolitan France : what todo with all "supossed to be wrong" name:xx ?

[Colin Smale via talk]

On 2019-11-19 16:40, Jóhannes Birgir Jensson wrote:

> Not all languages make, or care about making, a distinction of France 
> (including non-Europe) and France (only Europe).

This is not a question of language. They are different concepts, and
irrespective of the language you are speaking, it must be possible to
distinguish between the two. Of course it is possible that you need more
than two words for one or the other, using more descriptive terminology
instead of an accepted Proper Noun. 

If a language doesn't have a term for "Metropolitan France" then there
shouldn't be a name:xx in OSM.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Ordnance Survey OpenData

[Colin Smale]

On 2019-07-23 16:05, Alessandro Sarretta wrote:

> Just be careful that it seems that the OS OpenData license is not compatible 
> with OSM, see 
> https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility#Open_Government_Licence_.28OGL.29_based_licences

What about https://wiki.openstreetmap.org/wiki/Ordnance_Survey_Opendata
which says the OGL licence is compatible? What to you know that others
don't?___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Colin Smale]

On 2019-07-17 10:44, Rory McCann wrote:

> I don't think this counts as "tagging for the renderer", which is more about 
> adding false data to "make the map look like what you want" (e.g. "I want a 
> blue line here, like the `route=ferry` line, so I'll use that").
> 
> I think it could be very helpful for place names which aren't pronounced the 
> way you pronounce regular English words. e.g. in Ireland: "Dun Laoghaire" 
> [dun leary], "Tallaght" [tala], "Youghal" [yal], "Portlaoise" [port leash]. 
> This could be a problem even in England with places like "Reading", 
> "Worchester", "Cirencester".

And homographs like Gillingham (Kent) and Gillingham (Dorset) which are
pronounced differently (soft vs hard G) 

Oh what a wonderful language...___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Colin Smale]

On 2019-07-16 19:52, Jo wrote:

> If we were to make such exceptions, we would get into trouble really fast, as 
> some streets are signed differently on one end and on the other, depending 
> how big the street sign is, or in what period it was put there.

Don't shoot the messenger, I didn't write the wiki! 

> Expanding abbreviations is the norm. I try to do it even for first and middle 
> names of people, when the street is named after a person. That only works if 
> it's possible to find it somewhere, of course.

Apparently not everyone agrees with you, otherwise those exceptions
would not be noted in the wiki. Are you recommending that the exceptions
be removed from the wiki? 

> Polyglot 
> 
> On Tue, Jul 16, 2019 at 7:40 PM Colin Smale  wrote: 
> 
> On 2019-07-16 19:07, Nuno Caldeira wrote: 
> also on the the standard mapping convetions, its mentioned in bold : 
> 
> DON'T USE ABBREVIATIONS
> 
> https://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions 
> 
> But exceptions are made in some cases, including where the signage uses the 
> abbreviation: 
> 
> https://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Colin Smale]

On 2019-07-16 19:07, Nuno Caldeira wrote:

> also on the the standard mapping convetions, its mentioned in bold : 
> 
> DON'T USE ABBREVIATIONS
> 
> https://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions

But exceptions are made in some cases, including where the signage uses
the abbreviation: 

https://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Colin Smale]

The reason for wanting to expand abbreviations in OSM is surely to avoid
ambiguity, not specifically to aid pronunciation or recognition. In the
case of "1e ..." in a certain language context, would that not be
unambiguous? Would a speech synthesiser not know how it should be spoken
in its working language? 

Slight digression: The question does arise of which rules to use to
pronounce foreign names. If I am in Warsaw for example and my satnav
started pronouncing street names in pure Polish I might not recognise
any of them (apologies to any Poles in the audience). But how would it
speak such that I would recognise it, if I was looking for a string with
loads of Ws and Zs that means nothing to me? Use English rules to
pronounce a Polish word? 

On the other hand, if I was in Paris, I would expect it to use French
rules, because I understand French and using English rules would sound
weird although it might well give a lot of laughs...

On 2019-07-16 17:36, John Whelan wrote:

> This approach I like.  Name:expanded perhaps?
> 
> To go back to earlier ideas.
> 
> Expanding the name sounds sensible but unfortunately the street signs are 
> posted with the abbreviation and some local mappers have a what is on the 
> sign goes in the map mentality.  Also we have had discussions about street 
> names in Canada before and the decision was what the municipality declares 
> the street name is correct.  That was to do with either "rue Sparks" or 
> should it be "Rue Sparks" in Quebec it would be one way but in Ontario the 
> other.
> 
> Thoughts
> 
> Thanks John  
> 
> Colin Smale wrote on 2019-07-16 11:30 AM:
> 
> On 2019-07-16 16:54, John Whelan wrote: One or two are problematic usually as 
> the street name is an abbreviation.For example 1e Avenue in French 
> meaning First Avenue.
> 
> Any suggestions on how these should be handled?  This particular application 
> is aimed at partially sighted people but I feel we should be able to come up 
> with a generic solution. 
> 
> Some kind of phonetic (IPA?) representation would be the ultimate generic 
> solution. Here in NL (and I guess in many other countries) there are street 
> names which are partially or entirely in other languages, and the expectation 
> is that they are pronounced as such. For example, Boeing Avenue would sound 
> completely weird if it were pronounced according to Dutch rules. Truly 
> multi-lingual countries like Belgium and Switzerland should be able to make 
> use of name:XX. 
> 
> If we had name:XX:ipa=* we would have a place to put it, but the client app 
> would need to have a way of turning that into sounds. It will only be needed 
> if the pronunciation deviates from the standard for the language in question, 
> but speech synthesisers are never perfect and often make mistakes 
> 
> https://english.stackexchange.com/questions/264239/is-there-any-online-tool-to-read-pronounce-ipa-and-apa-written-words
>  
> 
> Of course we will also need a way of entering IPA symbols 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

-- 
Sent from Postbox [1] 

Links:
--
[1] https://www.postbox-inc.com___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Colin Smale]

On 2019-07-16 16:54, John Whelan wrote:

> One or two are problematic usually as the street name is an abbreviation.
> For example 1e Avenue in French meaning First Avenue.
> 
> Any suggestions on how these should be handled?  This particular application 
> is aimed at partially sighted people but I feel we should be able to come up 
> with a generic solution.

Some kind of phonetic (IPA?) representation would be the ultimate
generic solution. Here in NL (and I guess in many other countries) there
are street names which are partially or entirely in other languages, and
the expectation is that they are pronounced as such. For example, Boeing
Avenue would sound completely weird if it were pronounced according to
Dutch rules. Truly multi-lingual countries like Belgium and Switzerland
should be able to make use of name:XX. 

If we had name:XX:ipa=* we would have a place to put it, but the client
app would need to have a way of turning that into sounds. It will only
be needed if the pronunciation deviates from the standard for the
language in question, but speech synthesisers are never perfect and
often make mistakes 

https://english.stackexchange.com/questions/264239/is-there-any-online-tool-to-read-pronounce-ipa-and-apa-written-words


Of course we will also need a way of entering IPA symbols___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Ground truth for non-physical objects

[Colin Smale]

When Avon was dissolved in 1995, some of the new unitaries are actually
contained in their own counties. In the SI counties are created for
North West Somerset, Bath and North East Somerset, South Gloucestershire
and the City of Bristol; these counties are subsequently excused from
the obligation for every county to have a council. The new districts
which are created are coterminous with the counties of the same name
(actually it is defined in the opposite order; the districts are defined
by reference to the previous districts, and the extent of the new
counties are defined to be the same as the new districts.) 

http://www.legislation.gov.uk/uksi/1995/493/made 

On 2018-12-18 00:42, Colin Smale wrote:

> On 2018-12-17 23:16, Steve Doerr wrote: 
> On 17/12/2018 09:41, Colin Smale wrote: One other thing: in the UK the 
> boundaries of the area and the local authority running that area are two 
> different things. A local authority can run a combination of adjacent admin 
> areas; some admin areas are defined in law without there being a local 
> authority; and some admin areas are legally shared between councils. What we 
> have in the official sources (e.g. OS Boundary-Line) shows the geometry of 
> the areas, but it tells you nothing about the authority/ies "running" that 
> area. 
> 
> Hi, Colin. I'm British and I have no idea what you're talking about here. 
> Could you quote some examples that I could relate to?

Sure Steve. 

The laws (often SIs) that create an "admin boundary" do exactly that -
they define the boundary. In the case of counties and districts, which
are created by primary legislation, it is defined that there must be a
council. One of the embryonic council's first jobs is to decide on a
name: are we called "X Borough Council" or "Borough of X" (assuming
borough status) or something else? 

Think of Civil Parishes. There are many examples of Joint (or Group)
Parish Councils which operate in N (>1) civil parishes as a single
entity. The underlying parishes are what is defined in law, in terms of
their boundaries, and the information that they share a council is not
part of the definition of their boundaries. In Swale district,
Sheldwich,  Badlesmere and Leaveland Civil Parishes share a parish
council.  

Not all defined Civil Parishes have a council. Some smaller (in terms of
population) parishes make do with a Parish Meeting, in which essentially
all the electors are "councillors". In Maidstone borough, the parish of
Frinsted has only a Parish Meeting. 

There are a few examples of so-called "Lands Common" which are areas of
land which officially belong to 2 or more Civil Parishes, and are
therefore governed by multiple Parish Councils. The land concerned is
usually sparsely populated, or unpopulated, and the councils find a way
of working together when required. These are located in Devon, Yorkshire
and County Durham. 

And of course, there are many "unparished areas" (often in urban areas)
which do not fall within the boundary of a Civil Parish at all (e.g.
Gravesend and Northfleet). 

Thinking bigger: The non-metropolitan county of Berkshire exists,
although it does not have a council (the entire land area is divided up
into Unitary Authorities). In theory this situation applies to e.g.
Rutland and Herefordshire as well, but in this case the entire county
has been "divided" into a single Unitary Authority (which also calls
itself "Herefordshire County Council" / "Rutland County Council") so it
is not so noticeable. 

Hence, looking at a single point and establishing which OSBL polygons
contain it, does not tell you which councils have some role for that
location. 

Does that help? 
Colin___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Ground truth for non-physical objects

[Colin Smale]

On 2018-12-17 23:16, Steve Doerr wrote:

> On 17/12/2018 09:41, Colin Smale wrote: 
> 
>> One other thing: in the UK the boundaries of the area and the local 
>> authority running that area are two different things. A local authority can 
>> run a combination of adjacent admin areas; some admin areas are defined in 
>> law without there being a local authority; and some admin areas are legally 
>> shared between councils. What we have in the official sources (e.g. OS 
>> Boundary-Line) shows the geometry of the areas, but it tells you nothing 
>> about the authority/ies "running" that area.
> 
> Hi, Colin. I'm British and I have no idea what you're talking about here. 
> Could you quote some examples that I could relate to?

Sure Steve. 

The laws (often SIs) that create an "admin boundary" do exactly that -
they define the boundary. In the case of counties and districts, which
are created by primary legislation, it is defined that there must be a
council. One of the embryonic council's first jobs is to decide on a
name: are we called "X Borough Council" or "Borough of X" (assuming
borough status) or something else? 

Think of Civil Parishes. There are many examples of Joint (or Group)
Parish Councils which operate in N (>1) civil parishes as a single
entity. The underlying parishes are what is defined in law, in terms of
their boundaries, and the information that they share a council is not
part of the definition of their boundaries. In Swale district,
Sheldwich,  Badlesmere and Leaveland Civil Parishes share a parish
council.  

Not all defined Civil Parishes have a council. Some smaller (in terms of
population) parishes make do with a Parish Meeting, in which essentially
all the electors are "councillors". In Maidstone borough, the parish of
Frinsted has only a Parish Meeting. 

There are a few examples of so-called "Lands Common" which are areas of
land which officially belong to 2 or more Civil Parishes, and are
therefore governed by multiple Parish Councils. The land concerned is
usually sparsely populated, or unpopulated, and the councils find a way
of working together when required. These are located in Devon, Yorkshire
and County Durham. 

And of course, there are many "unparished areas" (often in urban areas)
which do not fall within the boundary of a Civil Parish at all (e.g.
Gravesend and Northfleet). 

Thinking bigger: The non-metropolitan county of Berkshire exists,
although it does not have a council (the entire land area is divided up
into Unitary Authorities). In theory this situation applies to e.g.
Rutland and Herefordshire as well, but in this case the entire county
has been "divided" into a single Unitary Authority (which also calls
itself "Herefordshire County Council" / "Rutland County Council") so it
is not so noticeable. 

Hence, looking at a single point and establishing which OSBL polygons
contain it, does not tell you which councils have some role for that
location. 

Does that help? 
Colin___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Licence for Sentinel Satellite images

[Colin Smale]

On 2018-12-17 19:40, Sérgio V. wrote:

> (BTW, sorry for typo in title, "License")

I see no typo in the title... Licence is the correct English spelling
:-)___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Ground truth for non-physical objects

[Colin Smale]

On 2018-12-17 14:14, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> On 17. Dec 2018, at 13:31, Tomas Straupis  wrote:
>> 
>> Especially interesting and useful would be stories of how maritime
>> boundaries or boundaries with no considerable obstructions built have
>> been actually mapped by physical observation.
> 
> as these are claims you can't observe them, you have to rely on the baseline 
> that the claiming country provides/defines and extend it by the buffer that 
> is claimed.

Aren't these maritime boundaries deposited with the UN under UNCLOS[1]?
Once that has been done, I would expect that it would be THAT version
that is most definitive, and no longer the drafts etc. made by the
claiming country. 

[1] http://www.un.org/Depts/los/LEGISLATIONANDTREATIES/index.htm___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Ground truth for non-physical objects

[Colin Smale]

On 2018-12-17 09:57, Martin Koppenhoefer wrote:

> Am Sa., 15. Dez. 2018 um 16:09 Uhr schrieb Colin Smale 
> : 
> 
>> "without access to the same sources" ... what if there is only one source of 
>> truth? With these non-observable items like admin boundaries that is often 
>> the case.
> 
> for admin boundaries there will often be at least 2 "true" document sources: 
> one for each party / side. They are also often observable, at least 
> punctually.

Looking at the UK position, I have to disagree with you here. Definitive
admin boundaries are administered by a "higher level". The two parties
to a common boundary do not have the authority to define the boundary
unilaterally. The "higher level" will tell them where there boundaries
are. Both parties refer to a single legal document (primary or secondary
legislation). So there is only one true source, but a variety of way of
getting there. You could ask each party for their understanding of where
the boundary is, but they don't own that information, they inherit it.
They should both point you at the same Statutory Instrument. 

There are legal processes for making changes to boundaries, which
sometimes have to be managed and/or reviewed by the LGBCE (Local
government boundary commission for England) or equivalent bodies in the
other nations. The result of the consulation process is a recommendation
to "change the law" which, on coming into force, becomes binding on the
parties named in the Statutory Instrument. 

One other thing: in the UK the boundaries of the area and the local
authority running that area are two different things. A local authority
can run a combination of adjacent admin areas; some admin areas are
defined in law without there being a local authority; and some admin
areas are legally shared between councils. What we have in the official
sources (e.g. OS Boundary-Line) shows the geometry of the areas, but it
tells you nothing about the authority/ies "running" that area.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Ground truth for non-physical objects

[Colin Smale]

"without access to the same sources" ... what if there is only one
source of truth? With these non-observable items like admin boundaries
that is often the case. Does "independent verifiability" now mean that
there must be at least two sources that agree before this criterion is
fulfilled? What qualifies as a source, anyway? If two people look at the
same tree, is that one source or two? Such observations are always
ephemeral anyway. 

The link to your blog was useful, thanks. I will read through it all
later, but my immediate reaction was that it is not a good idea to have
parallel fora, especially when discussing something as fundamental as
this. Either we do it here on the ML, or on your blog post, or on the
OSM wiki; but please, not in three places at once.

On 2018-12-15 15:24, Christoph Hormann wrote:

> On Saturday 15 December 2018, Colin Smale wrote: 
> 
>> Please choose your words more carefully. Sounds like [...]
> 
> I meant exactly what i wrote here.
> 
> For more details:
> 
> https://wiki.openstreetmap.org/wiki/Verifiability
> http://blog.imagico.de/verifiability-and-the-wikipediarization-of-openstreetmap/___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Ground truth for non-physical objects

[Colin Smale]

Please choose your words more carefully. Sounds like you are suggesting that 
everything needs to be dual sourced now. This kind of fundamental principle 
needs to be expressed with the same degree of care as a law, so it should be as 
simple as possible (but no simpler) and unambiguous.


On 15 December 2018 14:53:31 CET, Christoph Hormann  wrote:
>On Saturday 15 December 2018, Colin Smale wrote:
>> > The whole point of the "verifiability" and "ground truth"
>> > principles is so as _not_ to have to rely on documents.
>>
>> First time I have heard that as a (documented) rationale behind
>> "ground truth".
>
>Independent verifiability, i.e. that you can verify statements through 
>independent observation without access to the same sources is and has 
>always been the core of verifiability in OSM.
>
>-- 
>Christoph Hormann
>http://www.imagico.de/
>
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Ground truth for non-physical objects

[Colin Smale]

On 2018-12-15 12:54, Andy Townsend wrote:

> The whole point of the "verifiability" and "ground truth" principles is so as 
> _not_ to have to rely on documents.

First time I have heard that as a (documented) rationale behind "ground
truth". 

Surely the stronger requirement is public verifiability, from a freely
accessible, objectively reliable source. What is physically present in
situ is a subset of that - but so are public records. This would make
the mapping objective, in the sense that a random second mapper would be
able to verify the correctness of the data and/or come to the same
conclusion.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Board decision on Crimea complaint

[Colin Smale]

On 2018-12-11 13:53, Simon Poole wrote:

> As Frederik pointed out a bit back, this is just kicking the can down
> the road.
> 
> We will still have to make choices

Why? It would be better if OSM did not make choices, but represented
differing points of view equally, without expressing any kind of
preference. Keep out of politics, or it will not end well! Let the
renderer/user choose their preferred world view. 

Why not simply allow multiple manifestations of admin_level=2 with an
additional tag like "according_to". Job done.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Colin Smale]

On 2018-10-22 16:34, Mateusz Konieczny wrote:

> I strongly disagree, we map reality.

There is no one true reality, only perceptions. Which reality takes
precedence in your mind, may not be the same for everyone. Reality is
subjective. 

What is the test to apply to decide whether a point is included in
country A or country B? Is it who empties the rubbish bins perhaps? Is
it where the taxes are paid to? Is it what an arbitrary local would
answer to the question "what country are you in?" Putting it in
objective terms, and then applying the criteria consistently,
facilitates getting consensus. 

In the case of disputed borders, there are at least two realities (as
perceived by the parties to the dispute) and possibly a third reality as
perceived by a number of locals - who need to give objective answers to
carefully selected questions so that unintended bias is avoided.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Colin Smale]

On 2018-08-10 14:01, marekskleciak wrote:

> We have also mechanism for area routing but, that's true graphs are easier..

Do you have any links/references for area routing? What "mechanism" are
you thinking of here?___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] the new icon for the Tag:amenity=bureau_de_change

[Colin Smale]

On 2018-07-25 17:13, Daniel Koć wrote:

> W dniu 25.07.2018 o 16:39, Colin Smale pisze:
> 
>> The Red Crystal symbol is protected by the ICRC. We can't use it, nor can we 
>> use the Red Cross or Red Crescent. There have been numerous legal cases 
>> which came down to the fact that these symbols are protected by 
>> international law. Even historical representations (vintage ambulances, 
>> hospitals etc) have an issue with this.
> 
> Well, what about red cross symbol then - isn't it also protected by ICRC?...

Yes, and the red crescent as well.

> We had similar problem with shop=sports icon:

Yup, the IOC are fanatical as well.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

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

Re: [OSM-talk] the new icon for the Tag:amenity=bureau_de_change

[Colin Smale]

On 2018-07-25 17:13, Martin Koppenhoefer wrote:

> I guess it would be perceived as shooting themselves in the foot if the 
> international red cross would file a lawsuit against osmf for using a red 
> cross as icon for hospitals.

It has happened before. The ICRC are totally fanatical about the
protection of their emblems. Our symbol is mauve rather than red, so we
can get away with it like that. If we render a red cross (or crescent or
crystal) on our maps it will take a fraction of a nanosecond before the
ICRC (or some national organisation) are on our case.

Example quote from the Irish Red Cross website: 

"We frequently issue requests for organisations and companies to desist
from unauthorised use of the emblem which typically involves first aid
kits, medical products, surgeries, pharmacies, repair services,
children's toys, maps and street directories. This normally entails
either reproduction or stylising of the emblem."___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] the new icon for the Tag:amenity=bureau_de_change

[Colin Smale]

On 2018-07-25 16:05, Daniel Koć wrote:

> We have the same problem with hospital symbol. There's even an official
> generic symbol that we could use, called "red crystal" (see
> https://en.wikipedia.org/wiki/International_Red_Cross_and_Red_Crescent_Movement#The_Red_Crystal
> ) and I like it very much, but we still use red cross, because I think
> nobody would recognize it.

The Red Crystal symbol is protected by the ICRC. We can't use it, nor
can we use the Red Cross or Red Crescent. There have been numerous legal
cases which came down to the fact that these symbols are protected by
international law. Even historical representations (vintage ambulances,
hospitals etc) have an issue with this.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] "The Future of Free and Open-Source Maps" Slashdot.org , Saturday February 17, 2018

[Colin Smale]

On 2018-02-17 22:02, Jakob Mühldorfer wrote:

> Thanks for pointing it out to us!
> 
> I too have some thoughts on points in the article.
> One I agree with, one not
> 
> Let me start with this one:
> "No Support For Observational, or Other Datasets"
> This is the point I agree with.
> OSM is missing out on some valuable information due to this strict 
> "verifiable on the ground" policy.

The rule would better be expressed as "verifiable from public sources",
so that any member of the public can verify its correctness without
being privy to any secret or confidential knowledge. Admin boundaries
are a case in point; there is no dotted line across the fields, but the
route of the boundary is (usually) a matter of public record and
therefore verifiable without privileged access.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] "The Future of Free and Open-Source Maps" Slashdot.org , Saturday February 17, 2018

[Colin Smale]

Java and Javascript have only those four letters in common. They are
completely unconnected in all other respects.

On 2018-02-17 19:54, john whelan wrote:

> JAVA script is used by web sites.  It does not require JAVA to be installed.
> 
> JAVA itself may or may not be a security risk the issue is that it has been 
> declared one by the US government in the past and that means many 
> organisations will not permit it to be installed.
> 
> Relevant because it is a constraint and has an impact.
> 
> Cheerio John 
> 
> On 17 February 2018 at 13:48, Nicolás Alvarez  
> wrote:
> 
>> Curiously enough those same organizations and governments then run
>> Java web apps on their servers. Java isn't a security risk, Java
>> applets running inside a browser are the problem. And that's blocked
>> by browsers nowadays.
>> 
>> I don't understand why this is relevant to the original discussion though...
>> 
>> --
>> Nicolás
>> 
>> 2018-02-17 15:27 GMT-03:00 john whelan :
>>> The JAVA issue comes up as many use work machines and since JAVA has been
>>> identified by the US government as a security risk some time ago many
>>> organisations do not permit it's installation on their equipment.
>>> 
>>> Which means in simple terms you can't use the building_tool plugin when
>>> mapping buildings and with new mappers that hurts data quality.
>>> 
>>> Cheerio John
>>> 
>>> On 17 Feb 2018 1:18 pm, "Mike N"  wrote:
 
 On 2/17/2018 11:01 AM, James wrote:
> 
> except it wouldnt be multiplatform and only run on windows 🤢🤮. Java is
> a better alternative as it's a popular language and is multiplatform. 
> C/c++
> is a bit more complicated and not everyone can contribute.
 
 
 That's no longer true - .Net is open source and generates multiplatform
 code and the C# language has an open source reference.
 
 That being said, Java is quite suitable for JOSM, and the security issues
 would rarely if ever surface in JOSM.  The big question is how well does
 JOSM serve as an OSM editor?   Quite well by a number of indicators.
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Roundabouts - why is a separate segment required?

[Colin Smale]

Just to throw another concept into the mix... so-called flare roads,
where a road joining a roundabout (or other junction for that matter)
splits into two short one-way segments which go either side of an
obstacle. Mkgmap tries to recognise them by seeing if they come together
within X metres. Why is this important? It's about how you present the
turn-off angle to the user. If you look at the pure geometric angles of
the OSM ways up to the next node, taking the first exit can easily get
rounded to "straight on". By looking at where the exit road is after
(say) 50m the you have a more accurate impression about whether it is a
right turn or whatever. Sharing nodes between the ingress from one road
and the egress to the next road makes this all more difficult.

As I said before, this is not about routing in a mathematical sense
(traversing the routing graphs) but about how the resulting list of
nodes/edges is presented to the user. It's great if you can seen the
calculated route superimposed on a base map, but if the written/spoken
instructions don't correspond to your perception as you approach the
junction, then the system has failed. 

On 2018-02-15 11:05, Maarten Deen wrote:

> On 2018-02-14 19:39, Dave F wrote: On 14/02/2018 18:23, Johan C wrote:
> 
> No, they are not. Roundabouts are special types of intersections.  Which is 
> another type of intersection.
> 
> They have a way on which you can drive round. And round. And round.
> And they have other ways leading to and from this round way.
> Whenever you enter the roundabout you drive on this round way, even
> if it's just for a metre. And then you exit this round way on to a
> different way.
> 
> The present tagging (used since 2005 or so, and all around the
> globe) is fine. 
> To repeat myself. You can determine if you need to "drive on this
> round way" from a single node. No need for a section between entrance

You can not determine that from a single node. You need to load the
whole way that connects to that node and than make a judgement call
which roads connected to that node you will traverse (which you don't
know, because from a topology standpoint you are not traversing that
way).

It is like Matej's example.
Suppose it is mapped with the entry and exit road connected to one node.
Yes, you can see if there also connects a roundabout to that node and
you can make the determination that in that case you need to traverse
the roundabout in the correct direction.
But suppose there is not a roundabout connected but a (circular) way
with a oneway direction. Then you also need to make the decision that
you have to traverse that way.
But suppose the way is not circular (making you cross or touch a oneway
street), than you can not do that.
When is a road circular? Most roads are circular from a topology
standpoint, as in: you can reach a node on that way going in either
direction. So you can not determine from a topology standpoint if a road
is a circular road or a roundabout.

Your method of mapping makes for very elaborate edge cases and unwieldy
routing engines.

Regards,
Maarten

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

Re: [OSM-talk] Roundabouts - why is a separate segment required?

[Colin Smale]

Based on my experiences with mkgmap it's not so much a routing problem
as a navigation problem. The router will pick the correct path through
the graph but the translation to "human instructions" get confused, like
the exit numbers and the way the roundabouts display. Turning right at a
roundabout, i.e. taking the third exit, might show as straight on and
the instructions may refer to the first exit.

On 2018-02-14 17:39, Dave F wrote:

> I think I have read it correctly.
> 
> https://www.openstreetmap.org/node/5408566797
> 
> It is easy to determine this shared node is part of the roundabout as well as 
> the entrance from Wapping & can exit along Commercial, or if required, 
> continue around the roundabout:
> How is this different from, say, two side roads joining a main road at the 
> same node?,
> 
> Or even cross-roads. The router has to check to find out what road it's 
> crossing & find the appropriate exit, which, in the case of cross-roads, will 
> be on the same node.
> 
> DaveF
> 
> On 14/02/2018 16:17, Maarten Deen wrote: On 2018-02-14 15:53, Dave F wrote: Hi
> Could anyone give me an explanation for this line from
> https://wiki.openstreetmap.org/wiki/Tag:junction=roundabout
> 
> "Each road has to be connected with the roundabout in a separate
> node--that is, between these nodes a segment of the roundabout is
> required."
> 
> I see no requirement for a separate segment:
> 
> * When a entering road shares a node with a roundabout then the
> router knows it's entered that roundabout by reading the tags on the
> circular way.
> * Whilst on that node, the router checks to see if there are any
> suitable exits. If there are, then it leaves the roundabout.
> * If not, it continues going around until it finds an appropriate
> exit. 
> I'm not sure if you read the requirement right, but this tells mappers not to 
> connect the entry and exit road on the same node. If you were to map it that 
> way, the router will not see that you enter a roundabout and need to exit at 
> the first exit. It will just tell you to go right.
> It is not (what I think you think) that there needs to be a separate way 
> between entrance and exit, the roundabout can be mapped as one way in total.
> 
> Maarten

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

Re: [OSM-talk] OSM tagging validation lib

[Colin Smale]

Why bother anyway? Why not just leave it to FvGordon? 90k changesets
fixing other people's tagging errors... 

http://www.openstreetmap.org/user/FvGordon/history

Actually, an analysis of all these changesets might produce some
interesting insights into "frequently made errors". 

//colin 

On 2017-12-26 13:24, Simon Poole wrote:

> We already have validation tools in many forms for post-editing
> validation and already know how difficult they are to get "right" (see
> OSMOSE complaining about P+R facilities for a trivial example). I don't
> quite see why there is a need to create yet another one/system.
> 
> On the other hand validation on upload is horrible from a UI and
> workflow point of view (which is why JOSMs warnings get ignored so
> often). IMHO preventing inadvertent mistakes to start with seems to be
> far better and that can be done with consistent presets (which might
> have to be localized) and editor support (see what Bryan has just done
> with creating area geometries in iD).
> 
> Simon
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM tagging validation lib

[Colin Smale]

Hi Yuri, 

We have to decide what is most important - fidelity to the infinite
number of tagging styles out there, or the ability to get a basic set of
tagging grammar accepted in as many tools as possible. 

Any rules grammar will always have limits of course. If the rules are
too complex to represent in a declarative way, that is in itself an
indication of the mess we have got ourselves into. If the "unwritten
rules" of OSM tagging are too complex to write down, then they need
sorting out first! Having a simple base to work from might be a good
first step. Automated chaos is still chaos. 

I agree that the ultimate rules engine may well end up using e.g. JS as
a medium to express some of the subtleties of the rules. Once a JS
implementation has been published, then people can translate the JS
reference implementation into whatever language they need. But
separating the basic rules from the execution engine is nothing more
than architectural best practice, and there is no reason that the basic
rules should not be portable across runtime environments. 

Can you think of any complex patterns which cannot (easily) be expressed
in a declarative way? 

The real challenge here is not for the coders, but a perennial challenge
for the OSM community. How do we get to such a consensus about tagging
patterns, that we can actually say "this is correct" and "this is wrong
enough to warrant correction" without upsetting a large number of
people? As soon as a discussion is about right vs wrong, it degenerates
into mudslinging.

//colin 

On 2017-12-24 20:37, Yuri Astrakhan wrote:

> Declarative rules are usually not very good. Every tool must understand every 
> type of rule, and must be updated when new rule types are introduced. Plus 
> declarative grammar is either too limiting, or eventually starts looking like 
> a scripting language itself, and we end up building an execution environment 
> in every tool. 
> 
> I think a better path is executing scripts inside other languages, e.g.
> 
> * a JavaScript library ran by Java, Python, C++, ... 
> * a lib that gets compiled into a webassembly for browser, or connected to 
> other languages via native bindings (less tried path) 
> The lib would need an API to * access local data state * access master OSM DB 
> for additional data * access other tools like taginfo
> 
> Integrating scripting environment may be difficult, but offers far greater 
> benefits of rule consistency and flexibility. 
> 
> On Sun, Dec 24, 2017 at 7:30 AM, Colin Smale  wrote:
> 
> The technical differences between java and JS do not preclude generic 
> thinking. Consider tzdata[1] for example, which does something analogous for 
> time zone data. 
> 
> The "rules database" can be made portable, in the form of XML or JSON for 
> example. The logic for using these rules can be described in a portable way. 
> Then you add a set of compliance tests, and publish a reference 
> implementation to demonstrate that is is possible to implement it. After 
> that, the logic can be implemented in any language you like, checked against 
> the compliance tests and the bindings published. 
> 
> Externalising the rules database enables updates and customisations for 
> particular reasons. Depending on the specific use case and the associated 
> non-functionals, validation could possibly be offered as a cloud service (not 
> necessarily by OSM).
> 
> //colin 
> 
> [1] https://en.wikipedia.org/wiki/Tz_database [1]
> 
> On 2017-12-24 12:18, James wrote: 
> ID is javascript, JOSM is java. So right there I already see a 
> intercompatibility issue 
> 
> On Dec 24, 2017 6:12 AM, "François Lacombe"  wrote:
> 
> Hi 
> 
> Here is an idea I got regarding tagging validation in editors (iD, JOSM, 
> others). 
> Subsequently to wiki proposal voting and cleanups, it's currently necessarily 
> to open issues in each editor repository to ask for new tagging validation 
> rules.  
> 
> It can sometimes be time consuming to develop those new rules and such a work 
> is done independently by each project maintainer. While each project have its 
> own specific components, background logic is the same. 
> 
> Would a new lib called like osmtagvalidator or so in charge of doing conform 
> validation to wiki be useful? 
> It may be shared by any project involved in osm editing and preserve its 
> resources for other valuable developments. 
> 
> For me, validation doesn't prevent users to use tags they want, but only warn 
> them about possible mistakes. 
> 
> How would devs and users feel about this? 
> 
> All the best 
> 
> François 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lis

Re: [OSM-talk] OSM tagging validation lib

[Colin Smale]

The technical differences between java and JS do not preclude generic
thinking. Consider tzdata[1] for example, which does something analogous
for time zone data. 

The "rules database" can be made portable, in the form of XML or JSON
for example. The logic for using these rules can be described in a
portable way. Then you add a set of compliance tests, and publish a
reference implementation to demonstrate that is is possible to implement
it. After that, the logic can be implemented in any language you like,
checked against the compliance tests and the bindings published. 

Externalising the rules database enables updates and customisations for
particular reasons. Depending on the specific use case and the
associated non-functionals, validation could possibly be offered as a
cloud service (not necessarily by OSM).

//colin 

[1] https://en.wikipedia.org/wiki/Tz_database 

On 2017-12-24 12:18, James wrote:

> ID is javascript, JOSM is java. So right there I already see a 
> intercompatibility issue 
> 
> On Dec 24, 2017 6:12 AM, "François Lacombe"  wrote:
> 
>> Hi 
>> 
>> Here is an idea I got regarding tagging validation in editors (iD, JOSM, 
>> others). 
>> Subsequently to wiki proposal voting and cleanups, it's currently 
>> necessarily to open issues in each editor repository to ask for new tagging 
>> validation rules.  
>> 
>> It can sometimes be time consuming to develop those new rules and such a 
>> work is done independently by each project maintainer. While each project 
>> have its own specific components, background logic is the same. 
>> 
>> Would a new lib called like osmtagvalidator or so in charge of doing conform 
>> validation to wiki be useful? 
>> It may be shared by any project involved in osm editing and preserve its 
>> resources for other valuable developments. 
>> 
>> For me, validation doesn't prevent users to use tags they want, but only 
>> warn them about possible mistakes. 
>> 
>> How would devs and users feel about this? 
>> 
>> All the best 
>> 
>> François 
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk [1]
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
 

Links:
--
[1] https://lists.openstreetmap.org/listinfo/talk___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Questions about levels and fractional levels as well as how to handle them.

[Colin Smale]

Hallo John, 

A level is not a unit of measurement like a metre or a kilogram. If
level 1.5 exists, it only tells you that it is between level 1 and level
2. If a landing on a staircase between level 1 and level 2 is to be
assigned a level, it wouldn't make any difference if you called it 1.1
or 1.9, unless there are other fractional levels around of course. It is
the sequence of the levels that is important. If level numbers are
treated as floating point numbers, 1.10 would be before 1.9 (i.e. closer
to 1.0). If you treat them as strings, 1.10 is different to both 1.1 and
1.100 and may give unexpected results when sorting objects into level
order, e.g. for rendering. 

You may of course wish to use a convention of 0.1 levels = 0.5m for
example, if your levels are about 5m above each other. Having said that,
an integer level number is usually associated with a floor, and usually
increases in an upward direction. So something at "eye level" standing
on level 1, would definitely be between 1 and 2.

--colin 

On 2017-12-21 17:21, John Karr wrote:

> Hello All,  
> 
> I hope this is the correct mailing list to ask this question. I'm new to the 
> OSM community and had a question which I hear is very controversial. I'm part 
> of a team working on an app for indoor navigation using simple indoor 
> tagging. The audience for this app are individuals who are blind/low-vision 
> so that they can navigate indoor spaces.  I'm wondering how best to handle 
> fractional levels when parsing the repeat_on tag. Currently, the project does 
> not account for fractional levels and everyone involved seems to have a 
> different opinion on the matter, but not very many solutions emerged from the 
> discussion. And with that question more seem to arise. For instance, how 
> common are fractional levels mapped in the indoor plans? Are there any 
> standards or best practices associated with determining which fraction to dub 
> a level (i.e. 1.5, 1.2, 1.02, etc.)? I would love to know how the community 
> feels about this topic and how best to proceed. Also if anyone has an example 
> of a repeat_on
tag that contains fractional levels and how those are expressed that would be 
very much appreciated. 
> 
> Thanks, 
> John Karr
> Technology Product Research - Programmer I
> American Printing House for the Blind
> 1839 Frankfort Avenue
> Louisville, KY 40206-3148
> jk...@aph.org 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Mailing list security

[Colin Smale]

On 2017-11-25 17:59, Frederik Ramm wrote:

> Hi,
> 
> On 11/25/2017 11:12 AM, Colin Smale wrote: 
> 
>> I just got an email from the mailing list system that my
>> account/membership had been disabled due to "excessive bounces". I have
>> no idea why, but that is not the point I want to make here. My point is
>> that the email I received contained my password to that account, in
>> plain text!
> 
> Why don't we simply nuke all mailman passwords, they're not needed
> anyway. (All the lists I signed up for, I can't remember, either I
> didn't set a password, or Mailman assigned a random one, so it never
> occurred to me that there was anything to protect.)

Might not be a bad idea... System-generated passwords are at least
limited to that one system, and indeed, the worst that can happen is
likely to be that someone cancels your mailing list subscription. The
problem is that people, being human, might use their "usual" password
for multiple sites (despite warnings against this). If mailman is hacked
into revealing the passwords, some of them might be user-entered and may
provide access to other sites as well 

I expect OSM has some kind of "duty of care". If one is allowed to
choose one's own password, the operators need to take reasonable care to
prevent disclosure, and I don't expect a one-time warning would be
sufficient... but IANAL___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Mailing list security

[Colin Smale]

On 2017-11-25 17:31, Tom Hughes wrote:

> On 25/11/17 15:37, Colin Smale wrote: 
> 
> On 25 November 2017 16:04:45 CET, "Éric Gillet"  
> wrote: Another point : This password is not secure, but what the worst that
> could
> happen with it ? As long as one don't reuse it on other applications
> (as
> warned during registration), the only action an attacker could do would
> be
> to unsubscribe you. Not really catastrophic ...until it is hacked and 
> thousands of passwords are stolen. If even one of those leads to something 
> serious, I am not sure that saying "I told you so 10 years ago when you 
> signed up" will be enough to absolve the operators of liability.
> 
> I will open a ticket as suggested.

There's really not much point - we will upgrade as and when the packages
in Ubuntu are upgraded. We're not going to be installing from source. 

In that case I won't bother. I can't help thinking: what a sorry state
of affairs. 

When you say "we", who are you referring to exactly Tom?___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Mailing list security

[Colin Smale]

On 25 November 2017 16:04:45 CET, "Éric Gillet"  
wrote:
> Another point : This password is not secure, but what the worst that
>could
>happen with it ? As long as one don't reuse it on other applications
>(as
>warned during registration), the only action an attacker could do would
>be
>to unsubscribe you. Not really catastrophic
...until it is hacked and thousands of passwords are stolen. If even one of 
those leads to something serious, I am not sure that saying "I told you so 10 
years ago when you signed up" will be enough to absolve the operators of 
liability.

I will open a ticket as suggested.

//colin

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

Re: [OSM-talk] Mailing list security

[Colin Smale]

On 2017-11-25 11:53, Éric Gillet wrote: 

> This is non-ideal, but you were warned during your account creation that this 
> password is to be considered non-secure : 
> 
>> You may enter a privacy password below. This provides only mild security, 
>> but should prevent others from messing with your subscription. Do not use a 
>> valuable password as it will occasionally be emailed back to you in 
>> cleartext.

Thanks Éric, I admit that "I was warned" but I still find it scandalous
in this day and age... It seems this shortcoming in mailman was fixed in
V3, released in 2014. I read here that V3 no longer stores
unencrypted/decryptable passwords: 

https://mail.python.org/pipermail/mailman-users/2014-July/077411.html 

Are we still running V2.1? 

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

[OSM-talk] Mailing list security

[Colin Smale]

I just got an email from the mailing list system that my
account/membership had been disabled due to "excessive bounces". I have
no idea why, but that is not the point I want to make here. My point is
that the email I received contained my password to that account, in
plain text! 

WTF#1: Why is it remembering the cleartext password and not a
non-reversible hash? 

WTF#2: Why is it sending my password around in the email? 

My feeling is that this needs fixing, and quick. 

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

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

[Colin Smale]

The road classification suggests a default maxspeed, in the absence of
more explicit information. I don't understand why junction penalties
should be dependent on the road classes, and not on physical
characteristics. I guess this is just a heuristic which can be useful if
you don't have the full picture. 

I would like to take a closer look at your example route... Can you give
start and end locations?

--colin 

On 2017-08-22 13:13, Lester Caine wrote:

> On 22/08/17 11:41, Colin Smale wrote: 
> 
>> I agree,  classification should be largely irrelevant to routing.
>> Routing needs timings from node to node, which are best derived from
>> bendiness, number of lanes, junctions etc and then capped to the legal
>> maximum. A four-lane secondary, primary, trunk or motorway will all have
>> the same effective speed in the absence of bends and junctions.
> 
> The problem here is that most routing systems use the highway= tag as
> the initial key to defining the 'defaults' for a link and the delay
> elements added moving from one type of road to another. I am convinced
> there is a problem with the tagging of the B4632 which is preventing it
> from being seen as an alternative to the A46 10 mile detour but as yet
> I've not spotted anything wrong. Shortest routing will pick it up, but
> then avoids the M40/M6 for the next stage :( It's not just OSM routing
> that gives problems, other routing engines are showing similar detours
> around local 'shortcuts' ... so even within a single country
> harmonization is a problem ...___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Colin Smale]

I agree,  classification should be largely irrelevant to routing.
Routing needs timings from node to node, which are best derived from
bendiness, number of lanes, junctions etc and then capped to the legal
maximum. A four-lane secondary, primary, trunk or motorway will all have
the same effective speed in the absence of bends and junctions.

//colin 

On 2017-08-22 10:47, Lester Caine wrote:

> On 21/08/17 21:09, djakk djakk wrote: 
> 
>> Actualy, "highway=*" shuffles importance and characteristic of roads.
>> May we add an "importance" key to roads ?
> 
> Having spent the last week using OSMAND to navigate around the
> Welsh/Cheshire border area (UK ;) ), the 'importance' of roads is
> something of a problem even where the 'classification' of roads exists.
> Same problem in my own home area. OSMAND treats lower and unclassified
> roads as much lower importance when in many cases they ARE the main
> local route and this results in poor routing decisions! Importance can
> depend on why you are using the road? Things like 'speed_limit' need to
> be handled before adding another 'classification' tag?___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Colin Smale]

Hi Djakk, 

Interesting approach, which might work for Europe, but at the moment I
am not entirely convinced. What is strategic at a European level might
not be so strategic locally, and vice versa. The European numbers are
also not signposted everywhere, so there may be a challenge of
verifiability. I believe the European definition basically defines the
endpoints and a few waypoints, and it is left to national authorities to
join the dots as they wish. So it may or may not achieve your goal of
having a harmonised definition between countries. 

Are you actually sure there is a problem to be solved? Do you have
examples of inappropriate or inconsistent use of highway=trunk? 

//colin

On 2017-08-19 11:50, djakk djakk wrote:

> Hello Colin,  
> 
> I'm from Brittany, west part of France :) 
> 
> There is an equivalent of the "autoweg" sign in France. It is also tagged 
> with motorroad=yes. 
> https://fr.m.wikipedia.org/wiki/Panneau_d%27indication_d%27une_route_à_accès_réglementé_en_France
>  [1] 
> 
> So I was thinking using "highway=trunk" for strategic roads, not only for 
> motor roads, all over the world ...  
> For example in the Netherlands : 
> https://www.openstreetmap.org/#map=14/51.8977/4.2042 the N57, primary highway 
> between a trunk and a motorway, becomes trunk in the new tagging system ... 
> An other example, each European road which is not a motorway should be tagged 
> as a trunk road , it is not currently the case in France : 
> https://www.openstreetmap.org/way/42344655#map=15/46.4275/0.6306 
> 
> djakk 
> 
> Le ven. 18 août 2017 à 22:43, Colin Smale  a écrit : 
> 
> In the UK it is a specific road class, with its own style of signage. So it 
> is easily verifiable whether a road is a Trunk Road or not. Some Trunk Roads 
> are motorway-like, but others are standard two-way roads. So actually it is 
> not so much linked to the construction of the road, but to the fact that the 
> route is part of the government's strategic route network. 
> 
> In most/many other countries this distinction does not exist, so the use of 
> highway=trunk may become subjective unless a suitable definition is found. 
> For example, in the Netherlands an "autoweg" is usually mapped to 
> highway=trunk. These roads are indicated by a standard sign which you may 
> recognise (I don't know where you come from I'm afraid): 
> 
> https://nl.wikipedia.org/wiki/Autoweg#/media/File:Nederlands_verkeersbord_G3.svg
> 
> //colin 
> 
> On 2017-08-18 22:00, djakk djakk wrote: 
> Hello,  
> 
> highway=trunk is very different between countries, in France it is used for 
> motorway-like roads (dual carriageway), so the same road is sometimes 
> highway=primary and sometimes highway=trunk (example with the N7 road : 
> http://www.openstreetmap.org/#map=13/46.6303/3.2700), whereas in England or 
> in Japan highway=trunk is used like a highway=super-primary tag even if the 
> road is a urban street or a classic road (example : 
> http://www.openstreetmap.org/#map=17/51.62060/-0.78353).  
> 
> Should it be harmonized to the England standard ? 
> 
> djakk 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Links:
--
[1]
https://fr.m.wikipedia.org/wiki/Panneau_d%27indication_d%27une_route_%C3%A0_acc%C3%A8s_r%C3%A9glement%C3%A9_en_France___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Colin Smale]

In the UK it is a specific road class, with its own style of signage. So
it is easily verifiable whether a road is a Trunk Road or not. Some
Trunk Roads are motorway-like, but others are standard two-way roads. So
actually it is not so much linked to the construction of the road, but
to the fact that the route is part of the government's strategic route
network. 

In most/many other countries this distinction does not exist, so the use
of highway=trunk may become subjective unless a suitable definition is
found. For example, in the Netherlands an "autoweg" is usually mapped to
highway=trunk. These roads are indicated by a standard sign which you
may recognise (I don't know where you come from I'm afraid): 

https://nl.wikipedia.org/wiki/Autoweg#/media/File:Nederlands_verkeersbord_G3.svg

//colin 

On 2017-08-18 22:00, djakk djakk wrote:

> Hello,  
> 
> highway=trunk is very different between countries, in France it is used for 
> motorway-like roads (dual carriageway), so the same road is sometimes 
> highway=primary and sometimes highway=trunk (example with the N7 road : 
> http://www.openstreetmap.org/#map=13/46.6303/3.2700), whereas in England or 
> in Japan highway=trunk is used like a highway=super-primary tag even if the 
> road is a urban street or a classic road (example : 
> http://www.openstreetmap.org/#map=17/51.62060/-0.78353).  
> 
> Should it be harmonized to the England standard ? 
> 
> djakk 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Tool for users to add wikidata tags

[Colin Smale]

[reposting to list] 

The perfect is the enemy of the good things will rarely be 100%
right. Be satisfied with "good enough". Now, if someone could just come
up with a workable definition of "good enough" Or failing that, an
objective test to show whether A is better (closer to perfection,
without needing to define that) than B 

--colin

 On 2017-06-11 19:30, James wrote: 

> Well mapping from imagery would be "wrong" then as a lot of times it's 
> misaligned with the "real world" short of buying a 100 000$ gps receiver with 
> 1cm accuracy, there will always be "accuracy problems" 
> 
> On Jun 11, 2017 1:15 PM, "Colin Smale"  wrote:
> 
> On 2017-06-11 18:18, Eric Gillet wrote: 
> 
> On Thu, Jun 8, 2017 at 10:58 AM, Frederik Ramm  wrote:
> I am concerned that reckless users will use your tool to basically go
> over the planet in a "task manager" fashion, running the matching for
> square after square, selecting all matches and hitting upload. (On the
> basis of "hey if 95% of matches are good then I am improving OSM, right
> - someone local can sort out the 5% bad apples".) 
> 
> Should changesets which are less than 95% correct be disallowed on OSM ? That 
> would block a lot of contributions !

The easier it is to determine objectively whether data is "correct" or
not, the higher the bar should be. For example, for highway=motorway we
should expect nothing less than 100%. For many others, the criteria are
just too fuzzy to say with reasonable confidence if data is "correct" or
not so any discussion about tolerances is premature. 

--colin 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk [1] 

Links:
--
[1] https://lists.openstreetmap.org/listinfo/talk___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Tool for users to add wikidata tags

[Colin Smale]

On 2017-06-11 18:18, Eric Gillet wrote:

> On Thu, Jun 8, 2017 at 10:58 AM, Frederik Ramm  wrote:
> 
>> I am concerned that reckless users will use your tool to basically go
>> over the planet in a "task manager" fashion, running the matching for
>> square after square, selecting all matches and hitting upload. (On the
>> basis of "hey if 95% of matches are good then I am improving OSM, right
>> - someone local can sort out the 5% bad apples".)
> 
> Should changesets which are less than 95% correct be disallowed on OSM ? That 
> would block a lot of contributions !

The easier it is to determine objectively whether data is "correct" or
not, the higher the bar should be. For example, for highway=motorway we
should expect nothing less than 100%. For many others, the criteria are
just too fuzzy to say with reasonable confidence if data is "correct" or
not so any discussion about tolerances is premature. 

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

Re: [OSM-talk] Key:Destination Abbreviations

[Colin Smale]

I believe the phrase is "tagging wrongly for the renderer" - we
constantly consider the users/consumers of the data when tagging, but it
is clearly frowned upon to "lie" in the tagging to get something to show
up in a particular way or otherwise to achieve a particular effect.
Whether tagging is "correct" or not depends entirely on your frame of
reference. The destination of a road can also be derived geometrically
by following the road to see where it leads, but that would not be at
all useful or appropriate to the navigation use case.

 //colin 

On 2016-12-19 00:12, Andy Mabbett wrote:

> On 18 December 2016 at 21:40, Edwin Smith  wrote:
> 
>> 1) Destination is for the use of the navigation program.
> 
> That's a form of "tagging for the renderer".
> 
> Besides, if you wan to record, literally, what's on a sign, use
> something like 'transcription='___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Lot's of locality names in an otherwise empty area

[Colin Smale]

Have you tried contacting the mappers who created and last edited these
nodes? It looks like they were imported from some official source in
2011 and tidied up in 2014. 

--colin

On 2016-11-20 18:41, Sebastian Arcus wrote:

> I'm looking at the following section of OSM:
> 
> http://www.openstreetmap.org/#map=15/42.9959/-8.3908
> 
> I see lots and lots of locality names, on what the satellite imagery confirms 
> to be otherwise just empty fields and forests. I'm pretty sure I've seen this 
> elsewhere on OSM, in another part of the world. Does anybody know why are all 
> these place names there - in the middle of nowhere?
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM New Logo Proposal

[Colin Smale]

Normal practise is for the "marketing department" to have the logo
available in a selection of forms, for different purposes. Think of
different formats (square, 16:9, full-width banner etc), different
resolutions, different colour depths, perhaps a monochrome version etc.
In order to protect the "brand image" companies will have a selection
available which have all been individually "crafted" to look good for
the use case for which they are intended, and all "approved". The last
thing you want is random third parties all hacking it about in their own
way - then you would lose control of your own image. It's a bit of work,
but it only has to be sorted out once (per rebranding). The spot colours
also need specification of course, at least as RGB, CMYK and possibly
PMS. Don't forget that not all colours can be represented in RGB.

On 2016-10-15 11:11, Frederik Ramm wrote:

> Hi,
> 
> On 10/15/2016 08:03 AM, Yves wrote: 
> 
>> I personally find the 'negative magnifier' elegant, and the
>> disappearance of the 0s and 1s a good way to simplify this logo and make
>> it easier to scale.
> 
> I wonder what the established wisdom in the design community is about
> this. I mean, many people view the web site on a high-dpi screen with
> about a bazillion calibrated colours and we could have a super crafty
> logo with gradients and shadows and a shiny 3D effect and so on.
> 
> Then there are use cases where you want to logo on a T-shirt or in
> 16x16px in the corner of a map.
> 
> Does that automatically mean that you need to have the
> lowest-common-denominator logo that uses only 4 colours and is easily
> scalable - or are there ways to have a polished logo for large displays
> together with a scalable version and both still retain the same visual
> identity?
> 
> Of course even a simple logo can look good in large print but I do like
> it about the current logo that there are details to discover when you
> look closer.
> 
> Bye
> Frederik___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Multilingual feedback wanted for OpenStreetMap Carto

[Colin Smale]

Maybe these two-part names should be entered into the database using a
non-breaking hyphen (U+2011)?

//colin 

On 2016-09-19 09:52, Oleksiy Muzalyev wrote:

> On 18/09/16 04:32, Paul Norman wrote: 
> 
>> I'm looking for feedback from people who read non-latin languages on a 
>> proposed OpenStreetMap Carto font change. 
>> 
>> We are considering moving to Noto fonts and could use feedback from people 
>> who can read languages which have non-latin scripts, particularly Asian 
>> languages. I've made previews in about a dozen different languages at 
>> https://github.com/gravitystorm/openstreetmap-carto/pull/2349#issuecomment-247819822
>>  and want to check that there are no new problems. We may have to adjust 
>> font sizes, but that's a different issue. 
>> 
>> If you've got feedback, please leave it on 
>> https://github.com/gravitystorm/openstreetmap-carto/pull/2349
> 
> Hi Paul,
> 
> I noticed a slight bug for the Ukrainian alphabet. A hyphen "-" can be an 
> integral part of a town name, as opposite to indication of the division of a 
> word at the end of a line.
> 
> Here are some examples:
> 
> The name of the city of Kamianets-Podilskyi [1] (on Google map is written 
> correctly, on the OSM map wrongly, always in two lines): 
> 
> http://osm.org/go/0hmtaWQg-
> https://www.google.com/maps/@48.6906937,26.5564268,13z?hl=en
> 
> The town of Bilhorod-Dnistrovskyi [2] (again on Google map is written 
> correctly, on the OSM map wrongly, always in two lines): 
> 
> http://www.openstreetmap.org/#map=13/46.1517/30.3499
> https://www.google.com/maps/@46.1562394,30.4138062,11.81z?hl=en
> 
> It should be at least as Khanty-Mansiysk [3] in Russian Federation, in one 
> line at close zooms:
> 
> http://osm.org/go/2xZYTDR-
> https://www.google.com/maps/@61.0084264,69.0622292,12.98z?hl=en
> 
> or even better always in one line. For example, we do not write on the map 
> the names of New York or San Francisco in two lines. 
> 
> The names of these towns in Ukrainian are _Кам'янець-Подільський _and 
> _Білгород-Дністровський. _They are written normally in one line. These are 
> well-known towns in local culture. The first was founded in 12th century, the 
> second in 6th century BC (it's one of the most ancient cities of with a 
> continuous existence). 
> 
> Best regards,
> Oleksiy
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
 

Links:
--
[1] https://en.wikipedia.org/wiki/Kamianets-Podilskyi
[2] https://en.wikipedia.org/wiki/Bilhorod-Dnistrovskyi
[3] https://en.wikipedia.org/wiki/Khanty-Mansiysk___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Working with lat and long simply

[Colin Smale]

On 2016-09-10 18:55, Oleksiy Muzalyev wrote:

> Latitude and longitude are physical values, they will never change for a 
> house on Earth, no matter what. They do not depend on politics, economics, 
> linguistics of the current moment.

You sure about that? Plate tectonics means that everything is in motion,
albeit slowly. On top of that there have been a couple of "adjustments"
to WGS84 which have caused coordinates to change. 

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

Re: [OSM-talk] Without an address, an Icelandic tourist drew this map of the intended location (Búðardalur) and surroundings on the envelope. The postal service delivered!

[Colin Smale]

On 2016-08-30 20:25, Paul Johnson wrote:

> On Tue, Aug 30, 2016 at 1:19 PM, Colin Smale  wrote:
> 
>> We have - that's why I am whispering. But w3w is not intended for the US. 
>> It's for places which don't have addresses already, which apparently is a 
>> large part of the world. And I would be surprised if even a US delivery 
>> driver doesn't have a sat nav, which can easily deal with w3w (check out 
>> Navmii for example).
> 
> OK, then you seemed to miss the simple fact that, (gets out megaphone, aims 
> directly at Colin's head) NOBODY USES W3W BUT ALMOST EVERYONE KNOWS LATITUDE 
> AND LONGITUDE.

OK you win Paul, put away your megaphone and gather your toys up off the
ground. After all remembering two 7-digit floating point numbers is much
easier than remembering three words to the average person in these
underdeveloped areas. It must be my brain's off-day. Have you shared
your idea with USPS? Let's all use lat/lon and scrap all that silly
business with street names and zip codes. What's not to like? 

Oh, and tell all these people they are stupid as well 
http://what3words.com/using-what3words/delivery-ecommerce/___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Without an address, an Icelandic tourist drew this map of the intended location (Búðardalur) and surroundings on the envelope. The postal service delivered!

[Colin Smale]

On 2016-08-30 20:10, Paul Johnson wrote:

> On Tue, Aug 30, 2016 at 1:05 PM, Colin Smale  wrote:
> 
>> w3w solves the problem of you not having a (compact) answer to "what´s your 
>> address?" if you want to have something delivered. The fact that you only 
>> have to remember three words is for humans. But indeed the delivery person 
>> needs a computer.
> 
> I swear to god we've been over this... Not that it really helps when even in 
> the US, your average delivery driver's not going to make heads or tails of 
> purple,monkey,dishwasher in the first place, much less be able to sort it out 
> because their truck doesn't have a computer.

We have - that's why I am whispering. But w3w is not intended for the
US. It's for places which don't have addresses already, which apparently
is a large part of the world. And I would be surprised if even a US
delivery driver doesn't have a sat nav, which can easily deal with w3w
(check out Navmii for example).___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Without an address, an Icelandic tourist drew this map of the intended location (Búðardalur) and surroundings on the envelope. The postal service delivered!

[Colin Smale]

w3w solves the problem of you not having a (compact) answer to "what´s
your address?" if you want to have something delivered. The fact that
you only have to remember three words is for humans. But indeed the
delivery person needs a computer.

//colin 

On 2016-08-30 19:43, Florian Lohoff wrote:

> On Tue, Aug 30, 2016 at 07:24:02PM +0200, Colin Smale wrote: 
> 
>> I am going to say this very quietly what3words
> 
> I dont think what3words solves the issue of structured Addressing.
> 
> Addresses are typically strict hierarchical and offer some serious
> concepts you cant build with what3words.
> 
> "Fuzzy" or "Blurry" addresses - You cant express something like
> "between housenumber 5 and 10" or - "Across number 10 High Street".
> 
> Its exact in every aspect. 
> 
> Or a concept of "Naming all streets after birds in the north
> of the village and all streets after mammals on the south"
> every child can tell you the direction to walk and from the
> Name you get a rough guess where to head to.
> 
> When you tell them where is "allgemein.ausfüllen.fahrpreis" everybody
> will look a little confused.
> 
> What3Words is not made for humans, its made for Machines.
> 
> Flo___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Without an address, an Icelandic tourist drew this map of the intended location (Búðardalur) and surroundings on the envelope. The postal service delivered!

[Colin Smale]

I am going to say this very quietly what3words

On 2016-08-30 19:12, Florian Lohoff wrote:

> Hola,
> 
> On Tue, Aug 30, 2016 at 05:03:39PM +0200, Iván Sánchez Ortega wrote: Warning: 
> flame thread about to start.
> 
> El tirsdag 30. august 2016 16.50.14 CEST Oleksiy Muzalyev escribió: It is 
> clear that in Iceland there are street signs. However, a growing
> number of people on Earth is living in slums [1] or slum-like areas,
> where a classical system of addresses from the 19th century is not
> affordable. 
> Oh for fucks sake. Tell me what's not affordable about spray-painting letters 
> on the sides of buildings?

http://www.upu.int/en/activities/addressing/addressing-the-world-initiative.html
http://www.upu.int/fileadmin/documentsFiles/activities/addressingAssistance/brochureWhitePaperEn.pdf
http://www.upu.int/fileadmin/documentsFiles/activities/addressingAssistance/brochureAddressingTheWorldEn.pdf

Although i think the Upu has some serious conflicts in their members and
goals.

Deutsche Post and British Postal Service are both members, and both
claim copyright
on the postcode database. So the members of the UPU do not conform to
the claimed "public good"
of addressing. 

I think OSM could be a major piece in generating addresses for the
billions
currently unaddressed - still - its a huge task.

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

Re: [OSM-talk] What3words

[Colin Smale]

On 2016-07-13 12:24, Dave F wrote:

> On 13/07/2016 11:10, Frederik Ramm wrote: 
> 
>> W3W is a coordinate system...
> 
> I fail to see how it can even be described as that as there is no 
> coordination. The address of one block has no relation to adjacent ones.

Agreed - it's not a coordinate system, it's an addressing system, i.e. a
way of encapsulating a location in a convenient manifestation. 

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

Re: [OSM-talk] What3words

[Colin Smale]

On 2016-07-13 10:23, Lester Caine wrote:

> W3W and OLC both have the same problem. They are trying to fix something
> which is not really broken.

I disagree with this... They are not trying to replace / fix up lat/lon,
they are providing a lingua franca for people to use when communicating.
It's an alternate form of address, not an alternate form of location.
They are intended for use by humans - so being short, memorable and
reliable is an advantage. This is where W3W wins it from OLC as
accurately remembering three words is easier than remembering a "random"
sequence of symbols, and when you read it out over the phone the chances
of a misunderstanding producing an existing but wrong result are
minimal. 

They are like postcodes, whereby pretty much all other components of an
address are redundant (except for maybe apartment numbers). 

Us westerners are spoilt with our wonderful postal addressing systems...
There are many, many areas in the world which don't have street names or
even house numbers. Telling someone where you live means a whole chunk
of descriptive text like "second red building on the left". 

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

Re: [OSM-talk] NASA sites

[Colin Smale]

Is "NASA" really part of the actual name, or are you suggesting "tagging
for the renderer" because you expect to see "NASA" on the map? NASA is
certainly the operator, and that tag links the site to NASA. 

//colin

On 2016-06-27 14:38, Fabrizio Carrai wrote:

> Correct, without NASA in the name we miss the important relation with the 
> agency. 
> 
> 2016-06-27 13:29 GMT+02:00 Adam Schreiber :
> 
> NASA could be added to the operator tag.  That could cause some confusion 
> with regard to JPL as it's operated by the California Institute of Technology 
> for NASA. 
> 
> Cheers,
> Adam
> 
> On Jun 27, 2016 07:05, "Fabrizio Carrai"  wrote: 
> 
> Hello all, 
> I was checking about the NASA sites and I found the "NASA" term was not 
> always presente in the name tag: 
> 
> "Lyndon B. Johnson Space Center", Houston [1] 
> "Kennedy Space Center" (See Note below) 
> "Jet Propulsion Laboratory" , Pasadena, California [2] 
> 
> The Goddard is an exception (IMHO correct and complete) 
> 
> "NASA Goddard Space Flight Center" [3] 
> 
> Note: The Kennedy Space Center limits are not defined, I don't know if they 
> can be. 
> 
> Sometime "NASA" is indicated as "operator". What do you think, should NASA be 
> added to all the names ? 
> 
> Thanks for your opinion.
> 
> -- 
> 
> _FabC_ 
> _ _ 
> _[1] __http://www.openstreetmap.org/#map=15/29.5630/-95.0919_ 
> _[2] http://www.openstreetmap.org/way/374485271_ 
> _[3] http://www.openstreetmap.org/relation/4237285_ 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

  -- 

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

Re: [OSM-talk] [Talk-us] Old Aerodromes

[Colin Smale]

On 2016-04-12 16:29, Martijn van Exel wrote:

> I am not so concerned with rendering - that's not what we map for.

I think it would sound better if you said that rendering is one of the
many things we map for. OSM is not WOM (write-only memory). 

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

[OSM-talk] Please check the work of 00crashtest

[Colin Smale]

Hi, 

I would like to put out a worldwide alert for the work of 00crashtest
who has been tweaking things since January - 233 changesets and
counting... 

http://www.openstreetmap.org/user/00crashtest/history#map=4/45.53/-38.57


The problems I have seen include arbitrarily modifying admin boundaries
based on tourist information possibly other non-authoritative sources.
The boundaries of DC and the City of London are now incorrect/broken. I
am working on the City of London, exchanging changeset comments with the
user, but I can't do the whole world so I would encourage people to
check their area... 

Note that I think this is innocence and not vandalism, but they are
rather active at the moment and it would be great if we could repair and
limit the damage. 

--colin 

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

Re: [OSM-talk] Guides to improve navigation data in OpenStreetMap

[Colin Smale]

In the Netherlands just about everything that can apply to motor vehicles can 
also be found somewhere applying to bicycles. That includes turn lanes...
--colin

On 12 March 2016 14:12:25 CET, Arun Ganesh  wrote:
>>
>> this means that all turn:lanes, change:lanes, access:lanes,
>> forward:lanes, backward:lanes, etc. should count ALL lanes
>
>
>Turn lanes meant for a turn in a particular direction at the junction.
>I'm
>not sure if the concept of a turn lane extends to a cycle?
>
>The turn lane data should provide enough information to a car driver on
>which lane to take for a turn. Its obviously important to know the
>presence
>of a cycle lane in between the car turn lanes for proper guidance, and
>the
>main questions is if the `turn:lane` key is suitable for capturing this
>data.
>
>Arun
>
>
>
>
>
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Missing Background Layers

[Colin Smale]

I am seeing this as well... The list is only about half as long as it
was earlier today...

On 2016-01-08 23:13, Steve Doerr wrote:

> When editing in Potlatch 2, the list of background layers seems rather short. 
> In particular, Mapnik (the default style) is not on the list.
> 
> Bug? Or change of policy?
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Belgium/Netherlands Boundary Change

[Colin Smale]

Hi Steve, 

It's all under control with the local NL/BE communities. The decision
still needs to be ratified by the various parliaments before it takes
effect; that is expected to happen sometime this year. 

--colin

On 2016-01-05 12:54, Steve Doerr wrote:

> Just read this article about a territory-swap between The Netherlands and 
> Belgium: http://actualite24.info/post/316916
> 
> I wonder if this has taken effect yet? It's not reflected in OSM currently. I 
> think I'll leave it for the local communities to action.
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: OpenStreetMap Wiki page Map Features has been changed by David1234

[Colin Smale]

Hi Michael, 

Thanks for reverting... 

I could have reverted the changes indeed, but I just wanted to quickly
check first if it was possibly part of some deliberate action that had
been agreed beforehand.

Colin 

On 2015-12-26 11:49, Michael Reichert wrote:

> Hi Colin,
> 
> Am 2015-12-26 um 11:41 schrieb Colin Smale: 
> 
>> Anyone know what is going on here? A newly registered user has removed
>> all the content from an important wiki page (Map Features) and replaced
>> it with a test message...
> 
> I reverted his changes at Map_Features and will have a look at his other
> changes if there are any.
> 
> Btw, why didn't you revert the changes on your own? :-) It is very easy
> (compared to reverting at OSM).
> 
> Best regards
> 
> Michael
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Fwd: OpenStreetMap Wiki page Map Features has been changed by David1234

[Colin Smale]

Anyone know what is going on here? A newly registered user has removed
all the content from an important wiki page (Map Features) and replaced
it with a test message...

//colin 

 Original Message  

SUBJECT:
OpenStreetMap Wiki page Map Features has been changed by 
David1234

DATE:
2015-12-26 11:10

FROM:
OpenStreetMap Wiki 

TO:
Csmale 

REPLY-TO:
reply@not.possible

Dear Csmale,

The OpenStreetMap Wiki page Map Features has been changed on
26 December 2015 by David1234, see
http://wiki.openstreetmap.org/wiki/Map_Features for the current
revision. 

See
http://wiki.openstreetmap.org/w/index.php?title=Map_Features&diff=next&oldid=1244705
to view this change.

See
http://wiki.openstreetmap.org/w/index.php?title=Map_Features&diff=0&oldid=1244705
for all changes since your last visit.

Editor's summary: going for test This is a minor edit

Contact the editor:
mail: http://wiki.openstreetmap.org/wiki/Special:EmailUser/David1234
wiki: http://wiki.openstreetmap.org/wiki/User:David1234

There will be no other notifications in case of further activity unless
you visit this page while logged in. You could also reset the
notification flags for all your watched pages on your watchlist.

Your friendly OpenStreetMap Wiki notification system

--
To change your email notification settings, visit
http://wiki.openstreetmap.org/wiki/Special:Preferences

To change your watchlist settings, visit
http://wiki.openstreetmap.org/wiki/Special:EditWatchlist

To delete the page from your watchlist, visit
http://wiki.openstreetmap.org/w/index.php?title=Map_Features&action=unwatch

Feedback and further assistance:
http://wiki.openstreetmap.org/wiki/Help:Contents ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Nominatim weakness

[Colin Smale]

Could there also be sorting options for the result set? For example by
distance (nearest first), importance (the current algorithm?), ... 

And how about filters to show what you are looking for: returning
places, POIs, roads, ...

//colin 

On 2015-12-14 13:43, Jorge Gustavo Rocha wrote:

> Hi,
> 
> I think that we can add an option to bound the results to the current 
> viewport. That option would be passed to nominatim or any other search engine.
> 
> Personally, I would prefer the search bounded by default, but users could 
> change it to "everywhere" to see additional results.
> 
> Regards,
> 
> J. Gustavo
> 
> Às 11:17 de 14-12-2015, Martin Koppenhoefer escreveu: 
> 
>> 2015-12-14 10:04 GMT+01:00 Sarah Hoffmann > >:
>> 
>> If you type in 'Starbucks' in the search box, then you just get
>> objects named that way. No difference with searching for, say Berlin.
>> 
>> Now, if you type 'cafes' in the search box, then you are probably
>> looking for all amenity=cafe and that is a POI search. It's true
>> that this particular query doesn't work on osm.org .
>> You have to
>> additionally specify a place, e.g. 'cafes in Poughkeepsie' actually
>> returns the one Starbucks in town.
>> 
>> if I search for
>> "Starbucks in Holland" I get not hit, neither for
>> "Starbucks in the Netherlands"
>> "Starbucks in Netherlands"
>> "Starbucks in Amsterdam"
>> 
>> but "starbucks, Netherlands" yields a lot of results (there's even a
>> restaurant among them). Btw., also "starbucks, Holland" leads to a lot
>> of results (not sure if they are the sama, they are in different sorting
>> order at least). You can even omit the comma, but you shouldn't add an
>> "in" because this will lead to no results.
>> 
>> Cheers,
>> Martin
>> 
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Nominatim weakness

[Colin Smale]

It would be nice to have some shades of grey in there, like a choice of
radius, e.g. within 1km, 10km, 100km, 1000km

On 2015-12-14 13:43, Jorge Gustavo Rocha wrote:

> Hi,
> 
> I think that we can add an option to bound the results to the current 
> viewport. That option would be passed to nominatim or any other search engine.
> 
> Personally, I would prefer the search bounded by default, but users could 
> change it to "everywhere" to see additional results.
> 
> Regards,
> 
> J. Gustavo
> 
> Às 11:17 de 14-12-2015, Martin Koppenhoefer escreveu: 
> 
>> 2015-12-14 10:04 GMT+01:00 Sarah Hoffmann > >:
>> 
>> If you type in 'Starbucks' in the search box, then you just get
>> objects named that way. No difference with searching for, say Berlin.
>> 
>> Now, if you type 'cafes' in the search box, then you are probably
>> looking for all amenity=cafe and that is a POI search. It's true
>> that this particular query doesn't work on osm.org .
>> You have to
>> additionally specify a place, e.g. 'cafes in Poughkeepsie' actually
>> returns the one Starbucks in town.
>> 
>> if I search for
>> "Starbucks in Holland" I get not hit, neither for
>> "Starbucks in the Netherlands"
>> "Starbucks in Netherlands"
>> "Starbucks in Amsterdam"
>> 
>> but "starbucks, Netherlands" yields a lot of results (there's even a
>> restaurant among them). Btw., also "starbucks, Holland" leads to a lot
>> of results (not sure if they are the sama, they are in different sorting
>> order at least). You can even omit the comma, but you shouldn't add an
>> "in" because this will lead to no results.
>> 
>> Cheers,
>> Martin
>> 
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Graphic vector maps - Illustrator

[Colin Smale]

And you get prompted to allow cookies on the page containing the cookie
policy, which is daft. The cookie policy page is Shopify's, and does not
cover GA. You have to add GA to your web page yourself with Shopify, if
I recall correctly.

On 2015-12-07 16:26, Simon Poole wrote:

> Your website requires google analytics to be allowed (doesn't work without). 
> IMHO not a good idea considering your target audience.
> 
> Simon
> 
> Am 07.12.2015 um 12:50 schrieb Stijn Tallir: 
> 
>> Hi, 
>> 
>> Just to get the word out. 
>> 
>> As of last week Aquaterra has opened an online web-shop offering +1200 
>> digital open licensed graphic vector maps of the world in Adobe Illustrator 
>> format. The maps are derived from Openstreetmap data and are specifically 
>> designed for printing and publishing (DTP). 
>> 
>> Please take a look at our catalog here: http://www.mapshop.be 
>> 
>> We'll be updating the maps regularly and any suggestions to improve our 
>> products are welcome. 
>> 
>> Best regards, 
>> 
>> Stijn Tallir 
>> Aquaterra NV 
>> -- 
>> 
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] What3words

[Colin Smale]

 

The issue is as you say not an intrinsic problem with lat/lon but in the
devices used to measure it. The 3x3m grid should however be sufficient
for the purposes for which it is intended. It is not a designed as a
competitor to lat/lon. 

In the hypothetical tribal village in Africa, all it needs is a single
visit from a surveyor with cm-grade GPS kit to tell everyone their
coordinates. That's one end of the problem; the other end is that the
users of these coordinates will also need accurate coordinates, but this
time in real time (assuming they are searching for the right house, to
deliver something for example). 

By the way, for all the detractors of such a system, check out what the
UAE introduced recently - a fairly affluent country with a poor
addressing system. The difference is they use 10 digits which are
algorithmically linked to grid coordinates, instead of three words. 

http://www.citymetric.com/horizons/buildings-dubai-and-abu-dhabi-didnt-have-official-addresses-thats-finally-changing-838


On 2015-11-30 14:41, stegg...@steggink.org wrote: 

> Citeren Colin Smale :
> 
>> Correct, but the accuracy issue is a weakness in lat/lon based
>> coordinates as well. If you use your consumer GPS or phone to find your
>> lat/lon, you might indeed be a long way adrift and you might get
>> different values on different occasions. Imagine that you were relying
>> on that to get your shopping delivered...
> 
> It isn't the same issue. There isn't a weakness in the lat/lon system  itself 
> (unless you're not using enough digits), but the weakness is in  consumer GPS 
> devices as you say. When using w3w in combination with  GPS, you have to 
> convert it to lat/lon first, so you have to deal with  both the 3x3m 
> inaccuracy AND the inaccuracy of consumer GPS devices.
> 
> Frank
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] What3words

[Colin Smale]

 

Correct, but the accuracy issue is a weakness in lat/lon based
coordinates as well. If you use your consumer GPS or phone to find your
lat/lon, you might indeed be a long way adrift and you might get
different values on different occasions. Imagine that you were relying
on that to get your shopping delivered... 

In my example the party that needs to do the translation from w3w to
lat/lon would be Amazon, and they will probably be paying w3w for a
licence to do that. 

On 2015-11-30 13:30, Lester Caine wrote: 

> On 30/11/15 11:59, Colin Smale wrote: 
> 
>> I think their big attraction is the 75% (their figure) of the world that
>> doesn't have a functional address system. The added value in the UK is
>> indeed zero. In some tribal village in Africa for example where an
>> address might not get any better than "3rd mud hut on the left after the
>> group of 3 trees" the idea of giving all the dwellings a simple address
>> might open the world of e-commerce up to them. They will have an address
>> to use, and Amazon's drones will be able to find them. Maybe not today,
>> maybe not even tomorrow, but soon.
> 
> But 'What3words' can't actually locate them ... you HAVE to convert it
> to the GPS coordinates. Third hut on the left at least works without
> needing a mobile phone :) Doing the reverse process you need an accurate
> GPS system to establish the coordinates before you can convert that TO a
> w3w title. If the mapping system is only accurate to 10mts your android
> drone has a selection of targets. I've just looked up my own address in
> the UK and depending on which map overlay I select I got four different
> answers, some the next door addresses.
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] What3words

[Colin Smale]

 

I think their big attraction is the 75% (their figure) of the world that
doesn't have a functional address system. The added value in the UK is
indeed zero. In some tribal village in Africa for example where an
address might not get any better than "3rd mud hut on the left after the
group of 3 trees" the idea of giving all the dwellings a simple address
might open the world of e-commerce up to them. They will have an address
to use, and Amazon's drones will be able to find them. Maybe not today,
maybe not even tomorrow, but soon. 

On 2015-11-30 12:40, Lester Caine wrote: 

> On 22/11/15 14:32, Colin Smale wrote: 
> 
>> By the way, just to be absolutely clear, I am not thinking of w3w as a 
>> coordinate system in OSM, but as an addressing attribute similar to 
>> postcodes.
> 
> On one hand, one plugs in the three word location to their app and get a
> coordinate which takes you approximately to where you want to be. One
> needs the map to find the location in the first place, so if nothing is
> mapped one needs a precise coordinate ... so one logs the coordinate as
> well? I get the idea of 'what3words' but not while it has a page for
> pricing! It is something that should be a free world standard and there
> is nothing stopping the likes of HOT providing an alternative? But when
> one adds proper support for 6500+ languages building something
> inherently based on English is perhaps not the best starting point? All
> the uses I am seeing for it ALSO have the coordinates so it seems
> somewhat contrived trying to make it commercial in the first place?
> 
> The second you NEED an app to convert from one 'system' to another is
> there really any need to have some human readable name? Can I go to
> amuses.sizing.stream without an app, when I can go to
> uk.worcs.broadway.xxx by following signs?
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] What3words

[Colin Smale]

 

They stopped selling OneWords. 

https://twitter.com/what3words/status/594070034625986561 

On 2015-11-24 11:03, Tom Hughes wrote: 

> On 24/11/15 08:00, Paul Johnson wrote:
> 
>> Even if we completely ignore the licensing issues, there is a profit
>> motive behind w3w.  They gotta sell something.  And I'd be shocked if
>> it's not vanity words.  So, say I start telling friends about this
>> awesome sushi place at food.bear.utopia, but a competing eating
>> establishment buys the naming rights and has it changed to
>> sushi.sucks.ass.  Now you're not going to find your salmon sashimi at
>> food.bear.utopia because that's not a valid combination anymore.
> 
> It's no secret that they do that - it's called a "OneWord".
> 
> I'll grant you I can't easily see it on their web site right now but they 
> certainly were selling single word locators for a premium.
> 
> See eg http://techcrunch.com/2013/07/08/what3words/.
> 
> Tom
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] What3words

[Colin Smale]

I think their idea is that you can quote a location with the words which for 
humans is much easier to memorize and less prone to mishearing over dodgy phone 
and radio links than lat/lon or some other scientific grid reference.

On 24 November 2015 08:45:18 CET, Paul Johnson  wrote:
>On Sun, Nov 22, 2015 at 6:00 AM, Stefano  wrote:
>
>> Hi,
>> just for reference in May I saw a discussion on okfn-labs on "opening
>up"
>> w3w by doing an open location code system (different from the Google
>one).
>> https://lists.okfn.org/pipermail/okfn-labs/2015-May/001623.html
>>
>> See also https://github.com/pudo/open3words/issues/1
>>
>
>I hate to be the spoilsport here.  Given that latitude and longitude is
>already a thing that exists, is verifiable, widely used, universal, and
>potentially infinitely precise, yet granular to an entire degree of
>arc,
>and coherent (it's generally possible to visibly estimate proximity
>between
>two pairs of coordinates just by looking at them), it begs the
>question:
>How are these things extant?  o3w and w3w have zero buy-in, have no
>cogent
>pattern, are subject to change without rhyme or reason, and don't
>scale.
>It's like street addressing, but worse...
>
>
>
>
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] What3words

[Colin Smale]

 

True, they admit the 3D aspect cannot be handled at the moment. They
tend to emphasise the opposite: one building with a single address, but
multiple entrances; they can each have an individual w3w. 

On 2015-11-23 10:43, Martin Koppenhoefer wrote: 

> 2015-11-22 15:32 GMT+01:00 Colin Smale :
> 
>> You argument about being able to derive the w3w from the geometry is valid, 
>> but requires the use of the proprietary API. But as you mention their 
>> resolution is 3m, and I have seen discussions where people point out that 
>> their house falls into multiple squares so there is not a single translation 
>> from a building to w3w. ...
> 
>> By the way, just to be absolutely clear, I am not thinking of w3w as a 
>> coordinate system in OSM, but as an addressing attribute similar to 
>> postcodes.
> 
> it clearly is a coordinate system and not an addressing system. Addresses 
> adopt to the requirements, this system doesn't. Addresses are unique (at 
> least in the areas I know), this system can't guarantee it. If there are 2 
> doors side to side falling into the same grid square 3x3, they will get the 
> same "address" (coordinates) in w3w, despite having actually distinct 
> addresses (this is how addressing works in Italy, one address for every 
> entrace). 
> 
> cheers, 
> Martin
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] What3words

[Colin Smale]

 

On 2015-11-22 15:47, Dave F. wrote: 

> On 22/11/2015 14:32, Colin Smale wrote: 
> 
>> I just said "w3w exists, what could/should we do?"
> 
> The consensus appears to be "Nothing"

Agreed.

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

Re: [OSM-talk] What3words

[Colin Smale]

 

Hi Daniel, 

I didn't actually say there was any point in putting it in OSM, I just
said "w3w exists, what could/should we do?" 

You argument about being able to derive the w3w from the geometry is
valid, but requires the use of the proprietary API. But as you mention
their resolution is 3m, and I have seen discussions where people point
out that their house falls into multiple squares so there is not a
single translation from a building to w3w. People choose which w3w to
publish as "their location." An adjacent square has a completely
different w3w, so a human can't just visually assess whether it is close
or just plain wrong. An address may have multiple phone numbers, and the
inhabitants choose which one to publish; typically that one gets into
contact:phone=* in OSM. 

IF anyone wants to put their w3w into OSM, I don't think that would be
sufficiently wrong to require the data to be removed, even if the
concept is causing some raised eyebrows at the moment. 

By the way, just to be absolutely clear, I am not thinking of w3w as a
coordinate system in OSM, but as an addressing attribute similar to
postcodes. 

--colin 

On 2015-11-22 14:52, Daniel Kastl wrote: 

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi Colin,
> 
> Beside the different opinions about proprietary and closed technology,
> what is the point to add these 3 words as a tag? I don't really
> understand the benefit, because the relation between location
> (coordinates) and their address system is fixed. It's just a 3x3m grid.
> 
> In OSM every object has a geometry and you can query the w3w address
> just using their API. So I don't see the point where it makes sense to
> add such an address tag. It's like you add "latlon" as a tag.
> 
> Regards,
> Daniel
> 
> On 22/11/15 22:37, Colin Smale wrote: 
> 
> Andy, you are right, if you accept that the 3 or 4 people who have 
> participated in this discussion are representative of OSM at large.
> But the most active inhabitants of this list and others are limited
> to maybe 10 people, who frequently use authoritative-sounding
> language like "we are not doing it" and "it has no place in OSM"
> without the merest hint of "IMHO". I am not naming any names, and I
> don't want to get into any personal arguments, but it is a general
> frustration I have with the discussions on these lists.
> 
> There may be many arguments against w3w in OSM, but I was kind of
> hoping that some of the attacks would also apply objectively to
> other entities which are or are not mapped in OSM. On-the-ground
> visibility was mentioned, and that is spurious in the sense that
> there are many other things in OSM which are not visible and are
> yet tolerated. Being proprietary was mentioned, but it is not
> really much more proprietary than the coordinates of UK postcodes
> used to be, and we were happily reverse-engineering them and adding
> them to point addresses and deriving district boundaries from that
> data. Through all that effort the proprietary nature (and the
> commercial value) of the PAF was to some extent diluted, and now a
> lot of this information is publicly available. Only time will tell
> if w3w takes off commercially. Right now they have had $5m of
> funding and have an impressive list of partners.
> 
> --colin
> 
> On 2015-11-22 14:01, ajt1...@gmail.com wrote:
> 
> On 22/11/2015 12:51, Colin Smale wrote: 
> 
> ...and once again, as seems to be the norm in OSM, any
> minority interest which is not supported by the oligarchy gets
> mercilessly shot down.
> 
> ... except it's not _just_ the "oligarchy", is it?  No-one on
> this list seems to have a good word for the original idea.
> 
> Cheers,
> 
> Andy (SomeoneElse)
> 
> ___ talk mailing
> list talk@openstreetmap.org <mailto:talk@openstreetmap.org> 
> https://lists.openstreetmap.org/listinfo/talk

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

- -- 
Georepublic UG & Georepublic Japan
eMail: daniel.ka...@georepublic.de
Web: https://georepublic.info
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWUci6AAoJEHjh5kk/zBG0MkQH/3R0ROeV1V8ugjeddSNrNaBE
KL7gQreKBzhrg+YnysiZGjqBJ6i0dmpe6OimPAXrOLrhzu90LvZJZRfhhSmWi3ms
HuNLUJofcPqQybEoJTZ+khQpebMBFg0DatH5uQJYvg+0fTBMpQncKtUjTPlMXhZf
UWMZSQNEpPOq8BAZ1/aO1Kxvxd2VNTxBgznsyTSzqs1LY8oS5ZiRzMFBpODYwlI7
kiqI69M8LC/IUjX5iSetBH+fTucNJxguvVhjadJnusGW6n+7gLYyPcZnTdRy5Q1+
HtUhDHOXqZiFYEoVcbveHZnEKAiMq9qXpZvv6xwQS4RJmEQpKTS6aGLBZ9jKSuc=
=lpOg
-END PGP SIGNATURE-

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

Re: [OSM-talk] What3words

[Colin Smale]

 

Andy, you are right, if you accept that the 3 or 4 people who have
participated in this discussion are representative of OSM at large. But
the most active inhabitants of this list and others are limited to maybe
10 people, who frequently use authoritative-sounding language like "we
are not doing it" and "it has no place in OSM" without the merest hint
of "IMHO". I am not naming any names, and I don't want to get into any
personal arguments, but it is a general frustration I have with the
discussions on these lists. 

There may be many arguments against w3w in OSM, but I was kind of hoping
that some of the attacks would also apply objectively to other entities
which are or are not mapped in OSM. On-the-ground visibility was
mentioned, and that is spurious in the sense that there are many other
things in OSM which are not visible and are yet tolerated. Being
proprietary was mentioned, but it is not really much more proprietary
than the coordinates of UK postcodes used to be, and we were happily
reverse-engineering them and adding them to point addresses and deriving
district boundaries from that data. Through all that effort the
proprietary nature (and the commercial value) of the PAF was to some
extent diluted, and now a lot of this information is publicly available.
Only time will tell if w3w takes off commercially. Right now they have
had $5m of funding and have an impressive list of partners. 

--colin 

On 2015-11-22 14:01, ajt1...@gmail.com wrote: 

> On 22/11/2015 12:51, Colin Smale wrote: 
> 
>> ...and once again, as seems to be the norm in OSM, any minority interest 
>> which is not supported by the oligarchy gets mercilessly shot down.
> 
> ... except it's not _just_ the "oligarchy", is it?  No-one on this list seems 
> to have a good word for the original idea.
> 
> Cheers,
> 
> Andy (SomeoneElse)
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk