[Talk-us] Fwd: State of the Map 2014 - Buenos Aires - 07-09 November 2014

[Richard Weait]

Announced today, State of the Map 2014 will be in Buenos Aires.  Be
there or be square.  :-)

http://blog.openstreetmap.org/2014/01/12/buenos-aires-hosts-sotm14/

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

[Talk-us] Fwd: State of the Map 2014 - Buenos Aires - 07-09 November 2014

[Richard Weait]

-- Forwarded message --
From: Richard Weait 
Date: Sun, Jan 12, 2014 at 6:49 PM
Subject: State of the Map 2014 - Buenos Aires - 07-09 November 2014
To: Talk-CA OpenStreetMap 


Announced today, State of the Map 2014 will be in Buenos Aires.  Be
there or be square.  :-)

http://blog.openstreetmap.org/2014/01/12/buenos-aires-hosts-sotm14/

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

Re: [Talk-us] Oklahoma relations spreadsheet

[Paul Johnson]

It would be awesome if the state pages could show networks below the state
level.  Oklahoma has a lot of turnpikes, long-term detours, county routes,
indian roads and city routes that don't (or wouldn't, in the cases of yet
to be started relations) make the list now.
On Jan 12, 2014 4:24 PM, "Van Exel, Martijn"  wrote:

> There is MapRoulette.org/relationpages that gets generated every 4 hours.
> It needs an index page and I am open to other suggestions for improvement.
> The code  is on github too if you want to help out. Don't have the link
> handy right now.
>
> Sent from my iPhone
>
> On Jan 12, 2014, at 12:32 PM, "Peter Davies" 
> wrote:
>
> Paul
>
> This is really helpful in confirming to me that I can't use relations in
> my apps, as there are too many unfinished ones.  Can anyone tell me if they
> know of anyone else with such a spreadsheet for any other states?
>
> Peter
>
>
> On Sun, Jan 12, 2014 at 5:56 AM, Paul Johnson  wrote:
>
>> I'm working on an Oklahoma route relation 
>> spreadsheetto
>>  get a better grip on working status of route relations in Oklahoma.
>>  Please let me know if you want edit access on it (ie, you're actively
>> mapping Oklahoma) or if you happen to know the email address of other OK
>> mappers.
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Oklahoma relations spreadsheet

[Van Exel, Martijn]

There is MapRoulette.org/relationpages 
that gets generated every 4 hours. It needs an index page and I am open to 
other suggestions for improvement. The code  is on github too if you want to 
help out. Don't have the link handy right now.

Sent from my iPhone

On Jan 12, 2014, at 12:32 PM, "Peter Davies" 
mailto:peter.dav...@crc-corp.com>> wrote:

Paul

This is really helpful in confirming to me that I can't use relations in my 
apps, as there are too many unfinished ones.  Can anyone tell me if they know 
of anyone else with such a spreadsheet for any other states?

Peter


On Sun, Jan 12, 2014 at 5:56 AM, Paul Johnson 
mailto:ba...@ursamundi.org>> wrote:
I'm working on an Oklahoma route relation 
spreadsheet
 to get a better grip on working status of route relations in Oklahoma.  Please 
let me know if you want edit access on it (ie, you're actively mapping 
Oklahoma) or if you happen to know the email address of other OK mappers.

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


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

Re: [Talk-us] Oklahoma relations spreadsheet

[Paul Johnson]

You can use them in apps, I just wouldn't trust them to be complete for a
while now.


On Sun, Jan 12, 2014 at 1:31 PM, Peter Davies wrote:

> Paul
>
> This is really helpful in confirming to me that I can't use relations in
> my apps, as there are too many unfinished ones.  Can anyone tell me if they
> know of anyone else with such a spreadsheet for any other states?
>
> Peter
>
>
> On Sun, Jan 12, 2014 at 5:56 AM, Paul Johnson  wrote:
>
>> I'm working on an Oklahoma route relation 
>> spreadsheetto
>>  get a better grip on working status of route relations in Oklahoma.
>>  Please let me know if you want edit access on it (ie, you're actively
>> mapping Oklahoma) or if you happen to know the email address of other OK
>> mappers.
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Oklahoma relations spreadsheet

[Peter Davies]

Paul

This is really helpful in confirming to me that I can't use relations in my
apps, as there are too many unfinished ones.  Can anyone tell me if they
know of anyone else with such a spreadsheet for any other states?

Peter


On Sun, Jan 12, 2014 at 5:56 AM, Paul Johnson  wrote:

> I'm working on an Oklahoma route relation 
> spreadsheetto
>  get a better grip on working status of route relations in Oklahoma.
>  Please let me know if you want edit access on it (ie, you're actively
> mapping Oklahoma) or if you happen to know the email address of other OK
> mappers.
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Relation member order/structure: Why don't we do it in the road?

[Peter Davies]

Andrew,

I'm not so keen on route relations either.  In my view they are
duplicative, complex, confusing and costly to code. As a UK
traffic engineer I'd much rather that my US State DOT clients dropped the
practice of multi-banding many roads, so that each way would have one and
only one definitive ref, as is the case in most other countries.

Why? Drivers are not helped by sign clutter. It's a lot like texting.
 Messy signs are dangerous and distracting. The same is true for nav
systems, info systems and maps. Less is more.  Keep it simple.  This is
what the safety research shows.

In practice most US states already use the first-posted route designator
when fixing milepoints and motorway exit numbers, and I've asked OSM
mappers to list this first in the way ref. Then the other signed and
unsigned designators already follow for each way, using the infamous ";".
 Once that's been done, the relation carries almost no additional
information.  It doesn't even help us to assemble the ways as there is no
consensus on the sequencing order of ways in the relation, for complex
routes.

Is there another "way" forward?  Why don't we do it in the road?  (Thank
you, John Lennon.)   A radical way to solve the ragged discussions of these
past 3 months could be to put the posted cardinal direction on the way, as
well as the ref(s).  An example could be "ref=US 202:east;ME 11:north;ME
17:north;ME 100:east" replacing a relation at least 100 times longer, full
of complex data structures that are highly prone to error.

But here we violate  the 1 tag, 1 value rule even more than at present.
 Another way to "do it on the road" could be

ref=US 202
alt_ref:1=ME 11
alt_ref:2=ME 17
alt_ref:3=ME 100

This could satisfy those EU nations who hate the current US practice of
packing multiple values into one.  A bot could probably be written to
unpack every US way ref tag and rewrite it in the form shown above.  In
many case it would be just "ref=I 80" "alt_ref=US 6".

A major benefit would be to bring the US back into compliance with the rest
of the world, for example with the A4 past Amsterdam's Schipol Airport,
which has "ref=A4"
"int_ref=E 19".

There are already 914 alt_ref tags in use, worldwide.  A US bot could
swiftly make it millions.  The relations labour of love could continue, but
without holding up this year's system deployments.

If we then took one extra step we could capture the posted cardinal
directionality on the way as well:

ref=US 202:east
alt_ref:1=ME 11:north
alt_ref:2=ME 17:north
alt_ref:3=ME 100:east

Oops, now I've upset all of Germany AND America.  So how about

ref=US 202
alt_ref:1=ME 11
alt_ref:2=ME 17
alt_ref:3=ME 100
posted:1=US 202:east
posted:2=ME 11:north
posted:3=ME 17:north
posted:4=ME 100:east

Posting route confirmation signs and junction signs is really a separate
matter from route designation.  German autobahns use "destination=Berlin"
in the way that Americans use "posted=US 202 east", so why try to combine
all these separate functions into a single ref tag?

For two-way roads like the Augusta, Maine, case (Western Avenue, off I-95),
it *could *become:

posted:forward=US 202 east
posted:forward=ME 11 north
posted:forward=ME 17 north
posted:forward=ME 100 east
posted:backward=US 202 west
posted:backward=ME 11 south
posted:backward=ME 17 south
posted:backward=ME 100 west

OK, so this is long, but very few ways are quad-banded.  Also the backward
posting can be inferred from forward in 99.9% of cases.  It's only really
needed if we have:

posted:forward=Muskogee Turnpike south
posted:backward=Muskogee Turnpike east

which is *extremely *rare.  I think Paul Johnson will let us know if he can
definitely find it in Oklahoma.

Time to get it done and just "do it in the road?"

Peter



On Sun, Jan 12, 2014 at 4:27 PM, Andrew Hain wrote:

> Peter Davies  writes:
>
> > Does anyone know if the Europeans (of which I'm one, oops) have any plans
> to create route relations?  I have found none while in UK, NL, D, A, CH, I
> and F this past two weeks, but perhaps I didn't look hard enough.
> >
>
> Route relations for roads have occasionally be created in the UK but many
> mappers are not keen on them.
>
> http://thread.gmane.org/gmane.comp.gis.openstreetmap.region.gb/6235
> http://thread.gmane.org/gmane.comp.gis.openstreetmap.region.gb/6731
>
> Feel free to argue against from an international or any other viewpoint of
> course.
>
> --
> Andrew
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Relation member order/structure; best effort worth it?

[stevea]

From my viewpoint, a US crash is "On OK 165 northbound at Chandler 
Road." Currently it looks (from the OK spreadsheet and from my own 
impressions elsewhere) as if state road relations are still too far 
from completion for use this year in operational public information 
systems. And on named, un-numbered urban arterials, no-one has even 
started  to talk of creating route relations. Our OSM import 
algorithms will need to find all the OK 165 ways (or 44th Street, 
Phoenix ways) and assemble them automatically in an upstream to 
downstream order. We'd have to do that anyway in Europe and the rest 
of the world where no highway route relations exist, so it's 
probably the way we should go here in the Americas.  Does anyone 
know if the Europeans (of which I'm one, oops) have any plans to 
create route relations?  I have found none while in UK, NL, D, A, 
CH, I and F this past two weeks, but perhaps I didn't look hard 
enough.


Except for Interstates/freeways/highways, such "middle tier" road 
route relations seem like a sort of data structure that OSM neither 
has nor needs, but instead, you (and your business) need.  (I make no 
value judgement on the benefit of an "operational public information 
system" and I welcome the possibility that OSM might provide data 
input for them, but, to wit, discussions to get there are notably 
difficult).  OSM DOES have route relations, and this topic started on 
how those might be "better ordered."  WHY they might be better 
ordered has yet to be answered (I only speculate that further 
downstream algorithms might prefer data which are better ordered than 
more poorly ordered).  But it does appear that ordering of elements 
in relations is a large topic that has large implications if done vs. 
not done.  There appear to be reasons to do so, there appear to be at 
least the "manual" (human, think-about-it) way and the JOSM-automatic 
way (which I'm unfamiliar with).


It may be possible for my proposed OSM importer to generate 
automated OSM relations as an output from that "downstream sorting" 
process, but perhaps that would spoil a lot of mappers' fun at 
weekends and evenings?  We could also create automated relations for 
other countries, I suppose, but I'm not sure whether or not we 
should.  I'd like to hear thoughts on this.  We are still some 
months (or longer) away from reaching this capability, by the way, 
and don't even need to go there if you all hate the idea. We could 
just ignore OSM route relations and effectively create our own, 
internally, as we currently would have to in the other 80% of the 
world.  Our relations would be ordered lists of ways, single track, 
with no branches or loops, in linear reference order.  Does anyone 
want them (or not want them) exported back to OSM?


I don't hate the idea, I like it, but of course I'd like to "play 
with it" when it is more ready.  I would want to better understand 
why a particular order was chosen over others, see if routing 
algorithms (a VERY common use for geographic data) are more efficient 
with one vs. another style of ordering, etc.


Steve, you talk about manual v. automated sequencing of relations. 
I've experimented with JOSM ordering, most recently yesterday on 
Paul's Muskogee Turpike in OK, and previously in other states.  The 
sequencing that emerges has not been particularly easy to 
understand.  Sometimes a tiny branch way has been (in my view, 
wrongly) labelled with the state route ref, and the JOSM algorithm 
picks it as the start point for the whole route  For me, a better 
algorithm would probably begin with the most southerly or easterly 
unconnected way and build a series of linked collections of ways 
sorted by typical US milepoint positive direction, S to N or E to W. 
Anyway as long as mappers can adopt any order they like for ways in 
relations, my OSM importer will have to make its own sort decisions 
to get the ways in topological (linear reference) sequence from end 
to end.  Would you support rules or guidelines for preferred 
sequencing of way members of relations?  What do we do with breaks, 
branches, loops, alternating single and dual carriageways, etc, 
etc.?  My starting suggestion is that we use a sequence based on 
increasing linear references from 0.0 to the top end of the road, 
but that rule alone would not solve every situation.


Peter, this doesn't initially offend or seem like a bad choice, 
though it does certainly grease the skids for your purposes.  There 
isn't anything wrong with that FOR YOU, but I believe it is incumbent 
upon us (OSM, as a project) to consider this in the longer term and 
wider application.  It seems a difficult problem, there appear to be 
multiple solutions where one solution for a particular application is 
better than another, and it is difficult to strictly enforce "less 
pure data" getting written into OSM at the end of the day.  Plus, 
what we mean by "pure" or "preferred" or whatever is far, far from 
specific right now.

Re: [Talk-us] Relation member order/structure; best effort worth it?

[Volker Schmidt]

>
> Peter Davies  writes:
>
> >?Does anyone know if the Europeans (of which I'm one, oops) have any plans
> to create route relations? ?I have found none while in UK, NL, D, A, CH, I
> and F this past two weeks, but perhaps I didn't look hard enough.
> >
>
>
Route relations are routinely used for roads in Italy.

See:

   - http://wiki.openstreetmap.org/wiki/WikiProject_Italy/Autostrade
   (in Italian) for motorways
   - http://wiki.openstreetmap.org/wiki/WikiProject_Italy/Strade_Statali
   (in Italian) for Main Roads

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

Re: [Talk-us] new geocoder

[Mike N]

On 1/12/2014 9:47 AM, Randy Meech wrote:

so I've been experimenting with putting OSM data (US
only for now) into Elasticsearch.


 Looks fantastic!   One corner case that would be nice to handle is 
searching for a "street with directional" without the directional.


  Example:  North Laurens Street
  Search: Laurens St -> returns North Laurens Street as one of the 
suggestions.




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

Re: [Talk-us] new geocoder

[Randy Meech]

On Sun, Jan 12, 2014 at 10:20 AM, Ian Dees  wrote:
> Can you point to the code if it's available? I'd love to look at how you're
> pulling together the ElasticSearch documents.

Sure -- definitely available: https://github.com/mapzen/pelias

Here's the address class:
https://github.com/mapzen/pelias/blob/master/lib/pelias/address.rb

> How much disk space does the US index use?

Just under 60GB currently. Much of that is Quattroshapes, which are
stored as GeoJSON polygons. I'm currently indexing all named streets,
most addresses (haven't done interpolations yet), and the POIs I think
someone might possibly search for.

-Randy

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

Re: [Talk-us] Relation member order/structure; best effort worth it?

[Andrew Hain]

Peter Davies  writes:

> Does anyone know if the Europeans (of which I'm one, oops) have any plans
to create route relations?  I have found none while in UK, NL, D, A, CH, I
and F this past two weeks, but perhaps I didn't look hard enough.
> 

Route relations for roads have occasionally be created in the UK but many
mappers are not keen on them.

http://thread.gmane.org/gmane.comp.gis.openstreetmap.region.gb/6235
http://thread.gmane.org/gmane.comp.gis.openstreetmap.region.gb/6731

Feel free to argue against from an international or any other viewpoint of
course.

--
Andrew


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

Re: [Talk-us] new geocoder

[Ian Dees]

This is awesome, Randy.

Can you point to the code if it's available? I'd love to look at how you're
pulling together the ElasticSearch documents.

How much disk space does the US index use?


On Sun, Jan 12, 2014 at 8:47 AM, Randy Meech  wrote:

> I'm working on an app that requires a forward geocoder with
> autocomplete, so I've been experimenting with putting OSM data (US
> only for now) into Elasticsearch. There's still a lot to do, but it's
> ready to play with, so I figured I'd share the demo:
> http://mapzen.com/pelias/
>
> This uses Quattroshapes & Geonames for the admin hierarchy. OSM
> streets, addresses, and POIs get reverse geocoded into the hierarchy.
>
> There are three endpoints which we'd like to make widely available in
> the future, but for now these are for testing only & might
> break/change/vanish at any moment:
>
> Suggestions (works pretty well)
> http://api-pelias-test.mapzen.com/suggest?query=brook
>
> Reverse (works okay)
> http://api-pelias-test.mapzen.com/reverse?lat=40.68685&lng=-73.9885
>
> Search (needs work!)
>
> http://api-pelias-test.mapzen.com/search?query=1369%20coffee%20house%20cambridge
>
> Would love feedback, suggestions, help, etc!
>
> -Randy
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] new geocoder

[Randy Meech]

I'm working on an app that requires a forward geocoder with
autocomplete, so I've been experimenting with putting OSM data (US
only for now) into Elasticsearch. There's still a lot to do, but it's
ready to play with, so I figured I'd share the demo:
http://mapzen.com/pelias/

This uses Quattroshapes & Geonames for the admin hierarchy. OSM
streets, addresses, and POIs get reverse geocoded into the hierarchy.

There are three endpoints which we'd like to make widely available in
the future, but for now these are for testing only & might
break/change/vanish at any moment:

Suggestions (works pretty well)
http://api-pelias-test.mapzen.com/suggest?query=brook

Reverse (works okay)
http://api-pelias-test.mapzen.com/reverse?lat=40.68685&lng=-73.9885

Search (needs work!)
http://api-pelias-test.mapzen.com/search?query=1369%20coffee%20house%20cambridge

Would love feedback, suggestions, help, etc!

-Randy

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

Re: [Talk-us] Relation member order/structure; best effort worth it?

[Peter Davies]

I am very interested to see Paul Johnson's OK relation completion
spreadsheet, as I'm trying to make a business decision on whether to use
relations when importing OSM data into into our state DOT traffic
information applications. These apps are neither navigation nor mapping,
but share some characteristics with navigation in that we want to use OSM
data to describe incident locations in plain English (or French, Spanish,
German, ...) rather than travel directions in plain English, etc. For this
we need the signposted cardinal directions in countries that follow AASHTO
style route numbering practices with cardinal direction plates (North,
South, East, West, or the same in French or Spanish).  Mostly I believe
these countries are in the Americas, though I'd love to hear from anyone
who knows of other national or regional examples.

>From my viewpoint, a US crash is "On OK 165 northbound at Chandler
Road." Currently it looks (from the OK spreadsheet and from my own
impressions elsewhere) as if state road relations are still too far from
completion for use this year in operational public information systems. And
on named, un-numbered urban arterials, no-one has even started  to talk of
creating route relations. Our OSM import algorithms will need to find all
the OK 165 ways (or 44th Street, Phoenix ways) and assemble them
automatically in an upstream to downstream order. We'd have to do that
anyway in Europe and the rest of the world where no highway route relations
exist, so it's probably the way we should go here in the Americas.  Does
anyone know if the Europeans (of which I'm one, oops) have any plans to
create route relations?  I have found none while in UK, NL, D, A, CH, I and
F this past two weeks, but perhaps I didn't look hard enough.

It may be possible for my proposed OSM importer to generate automated OSM
relations as an output from that "downstream sorting" process, but perhaps
that would spoil a lot of mappers' fun at weekends and evenings?  We could
also create automated relations for other countries, I suppose, but I'm not
sure whether or not we should.  I'd like to hear thoughts on this.  We are
still some months (or longer) away from reaching this capability, by the
way, and don't even need to go there if you all hate the idea. We could
just ignore OSM route relations and effectively create our own, internally,
as we currently would have to in the other 80% of the world.  Our relations
would be ordered lists of ways, single track, with no branches or loops, in
linear reference order.  Does anyone want them (or not want them) exported
back to OSM?

Steve, you talk about manual v. automated sequencing of relations. I've
experimented with JOSM ordering, most recently yesterday on Paul's Muskogee
Turpike in OK, and previously in other states.  The sequencing that emerges
has not been particularly easy to understand.  Sometimes a tiny branch way
has been (in my view, wrongly) labelled with the state route ref, and the
JOSM algorithm picks it as the start point for the whole route  For me, a
better algorithm would probably begin with the most southerly or easterly
unconnected way and build a series of linked collections of ways sorted by
typical US milepoint positive direction, S to N or E to W. Anyway as long
as mappers can adopt any order they like for ways in relations, my OSM
importer will have to make its own sort decisions to get the ways in
topological (linear reference) sequence from end to end.  Would you support
rules or guidelines for preferred sequencing of way members of relations?
 What do we do with breaks, branches, loops, alternating single and dual
carriageways, etc, etc.?  My starting suggestion is that we use a sequence
based on increasing linear references from 0.0 to the top end of the road,
but that rule alone would not solve every situation.

Paul, you don't like directional roles on the member ways of route
relations, and I think your solution is to create three relations per
route.  I would call these directions positive (increasing linear
reference, corresponding loosely with increasing milepoints), negative (the
reverse) and both directions (the parent).  We would post the cardinal
directions using tags for each whole directional relation. However where
the Muskogee Turnpike turns from E-W to S-N, or has some even more complex
deal such as E +ve and N -ve, the 3-relation method will fail. We could
further extend it by breaking the relations at the turns (strictly, at the
directional posting changes), having maybe nine relations for a complete
rectangular beltway (2 on each of the N, S, W, and E sides, plus a parent)
but Martijn and Kristen Kam have wanted to avoid relation proliferation.
This is why Martijn's firm (and OSM mappers) have adopted a hybrid system,
as I understand it, using posted directions on roles for complex routes,
and posted directions on directional relations for simple Interstates like
I 5.

Right now I don't think Talk-us has been able to solve the