Re: [OSM-talk] OSM cycle map - ?excessive focus on long-distance routes

[Richard Mann]

On Wed, May 9, 2012 at 3:09 PM, Richard Fairhurst wrote:

> But as yet I haven't understood what point you're trying to make in this
> thread. Without trying to be obtuse... can you explain?
>
> cheers
> Richard
>
That there are legitimate ways of classifying cycle routes other than for
touristic purposes (and it's not just me; it seems to be a known, if
unresolved, distinction in Utrecht).

OSM tagging of cycle routes seems dominated by the touristic approach, and
this limits the usefulness of the data if you're more interested in utility
cycling.

Looking at the Dutch guidance, they define a main cycle route as one that
has more than 2000 cyclists per day (other countries might settle for a
lower threshold!). These account for about 20% of the lanes/tracks, but
about 80% of the distance cycled. At that sort of volume, signposting is a
bit irrelevant; it's more down to observing the dominant flows of cyclists
(typically reinforced by above-average facilities, though not always). In
an ideal world, you'd do proper counts and derive the data from bottom up,
but given that it's usually pretty obvious, I think a certain amount of
duck-tagging is appropriate.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM cycle map - ?excessive focus on long-distance routes

[Andy Robinson]

But why does this need special treatment? We don't do it for any other mode
of transport.

 

Cheers

Andy

 

From: Richard Mann [mailto:richard.mann.westoxf...@gmail.com] 
Sent: 10 May 2012 10:08
To: Richard Fairhurst
Cc: talk@openstreetmap.org
Subject: Re: [OSM-talk] OSM cycle map - ?excessive focus on long-distance
routes

 

On Wed, May 9, 2012 at 3:09 PM, Richard Fairhurst 
wrote:

But as yet I haven't understood what point you're trying to make in this
thread. Without trying to be obtuse... can you explain?

cheers
Richard

That there are legitimate ways of classifying cycle routes other than for
touristic purposes (and it's not just me; it seems to be a known, if
unresolved, distinction in Utrecht). 

 

OSM tagging of cycle routes seems dominated by the touristic approach, and
this limits the usefulness of the data if you're more interested in utility
cycling.

 

Looking at the Dutch guidance, they define a main cycle route as one that
has more than 2000 cyclists per day (other countries might settle for a
lower threshold!). These account for about 20% of the lanes/tracks, but
about 80% of the distance cycled. At that sort of volume, signposting is a
bit irrelevant; it's more down to observing the dominant flows of cyclists
(typically reinforced by above-average facilities, though not always). In an
ideal world, you'd do proper counts and derive the data from bottom up, but
given that it's usually pretty obvious, I think a certain amount of
duck-tagging is appropriate.

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

[OSM-talk] NLSF & OSM cooperation

[Pekka Sarkola]

Hi,

 

Sorry about cross-posting, but I'd like cover necessary amount of people as
soon as possible.

 

As you may know National Land Survey of Finland has open all their
topographic datasets. Check my email from imports-lists:
http://lists.openstreetmap.org/pipermail/imports/2012-May/001386.html

 

There is a lot of discussion in Finnish on IRC-channel (osm-fi) and forums
(less in talk-fi). We are planning usage of NLSF datasets and discuss about
legal issues.

 

It seems that there have been several people who have contacted National
Land Survey of Finland. Behalf of OpenStreetMap. Officially OSM Foundation
hasn't been in contact to NLSF. As far as I know. This several people
contacting to NLSF behalf of the OSM is confusing. At least for NLSF.

 

So, I name myself to be point of contact between OpenStreetMap community and
National Land Survey of Finland. I know all the decision makers in NLSF and
my 20+ years' experience about Finnish GIS community will benefit both
parties. 

 

Unless there is anybody else who like to be PoC between OSM and NLSF, I
presume that this nomination has been accepted by OSM community. Those who
had has connections to NLSF regarding OSM cooperation (include imports,
legal, technical), should report to community about their efforts, goals and
results.

 

Further discussions should be in talk-fi, in Finnish or in English. Swedish
is also allowed because it's official language of Finland ;-)

 

Best Regards,

 

Pekka Sarkola

 

--

Pekka Sarkola

Gispo Oy

  pekka.sark...@gispo.fi   - GSM +358 40 725
2042

  www.gispo.fi -  
www.paikkatieto.com 

 

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

Re: [OSM-talk] OSM cycle map - ?excessive focus on long-distance routes

[Richard Mann]

We do it for motorised vehicles.

On Thu, May 10, 2012 at 11:21 AM, Andy Robinson  wrote:

> But why does this need special treatment? We don’t do it for any other
> mode of transport.
>
> ** **
>
> Cheers
>
> Andy
>
> ** **
>
> *From:* Richard Mann [mailto:richard.mann.westoxf...@gmail.com]
> *Sent:* 10 May 2012 10:08
> *To:* Richard Fairhurst
> *Cc:* talk@openstreetmap.org
> *Subject:* Re: [OSM-talk] OSM cycle map - ?excessive focus on
> long-distance routes
>
> ** **
>
> On Wed, May 9, 2012 at 3:09 PM, Richard Fairhurst 
> wrote:
>
> But as yet I haven't understood what point you're trying to make in this
> thread. Without trying to be obtuse... can you explain?
>
> cheers
> Richard
>
> That there are legitimate ways of classifying cycle routes other than for
> touristic purposes (and it's not just me; it seems to be a known, if
> unresolved, distinction in Utrecht). 
>
>  
>
> OSM tagging of cycle routes seems dominated by the touristic approach, and
> this limits the usefulness of the data if you're more interested in utility
> cycling.
>
>  
>
> Looking at the Dutch guidance, they define a main cycle route as one that
> has more than 2000 cyclists per day (other countries might settle for a
> lower threshold!). These account for about 20% of the lanes/tracks, but
> about 80% of the distance cycled. At that sort of volume, signposting is a
> bit irrelevant; it's more down to observing the dominant flows of cyclists
> (typically reinforced by above-average facilities, though not always). In
> an ideal world, you'd do proper counts and derive the data from bottom up,
> but given that it's usually pretty obvious, I think a certain amount of
> duck-tagging is appropriate.
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] NLSF & OSM cooperation

[Kaj-Michael Lang]

On Thu, 2012-05-10 at 13:46 +0300, Pekka Sarkola wrote:
> I know all the decision makers in NLSF and my 20+ years’ experience
> about Finnish GIS community will benefit both parties. 

Sounds good to me. And the import plans sounds good too.

-- 
Kaj-Michael Lang 


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

Re: [OSM-talk] OSM cycle map - ?excessive focus on long-distance routes

[Cartinus]

On 05/10/2012 11:08 AM, Richard Mann wrote:
> On Wed, May 9, 2012 at 3:09 PM, Richard Fairhurst wrote:
> 
>> But as yet I haven't understood what point you're trying to make in this
>> thread. Without trying to be obtuse... can you explain?
>>
>> cheers
>> Richard
>>
> That there are legitimate ways of classifying cycle routes other than for
> touristic purposes (and it's not just me; it seems to be a known, if
> unresolved, distinction in Utrecht).

Again: The lines on the map of the city of Utrecht are not routes at all.

They are roughly the ways busiest with cyclist radiating out of the
central railway station. Even for it's purpose it is fairly useless,
since it misses all the important tangential "routes".

There are similar maps made by the city of Utrecht for car traffic. As
usual the holy cow of western society (the car) gets more attention and
these maps have move detail (like traffic in tangential directions and
neighbourhood feeders). The local mappers used these as a rough
guideline for which roads to map as primary, secondary and tertiary.

That is the normal flow of information. You can use the (overly)
generalized maps made for policy making to selectively add information
to OSM, but making these style of maps always requires human editors of
the map (not just of the map data).

---
m.v.g.,
Cartinus

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

Re: [OSM-talk] OSM cycle map - ?excessive focus on long-distance routes

[Steve Doerr]

On 10/05/2012 13:02, Cartinus wrote:

the holy cow of western society (the car)


You mean the means of locomotion which has been chosen by the majority 
given freedom of choice?


--
Steve

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

Re: [OSM-talk] OSM cycle map - ?excessive focus on long-distance routes

[Cartinus]

On 05/10/2012 02:15 PM, Steve Doerr wrote:
> given freedom of choice?

This is getting way off-topic, but...

I know it is hard to accept for a lot of people, but the more people you
put in a smaller space the less freedom of choice you have. For an
example you might understand given your previous reaction: Look at how
many people living on Manhattan (NY) own a car.


---
m.v.g.,
Cartinus

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

[OSM-talk] Kickstarter for Haitian Creole OpenStreetMap Book

[Kate Chapman]

Hi All,

I just wanted to draw your attention to a project HOT is working on in
conjunction with Community OpenStreetMap Haiti.

We are having a Kickstarter fundraiser for a translation sprint. The
sprint will translate the Free OpenStreetMap book from French into
Haitian Creole.

To have OpenStreetMap continue to grow in Haiti it is vital that more
materials are available in Haitian Creole.

http://hot.openstreetmap.org/updates/2012-05-10_back_the_first_haitian_creole_openstreetmap_book

Thanks!

-Kate

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

Re: [OSM-talk] OSM cycle map - ?excessive focus on long-distance routes

[Steve Doerr]

On 10/05/2012 13:41, Cartinus wrote:

On 05/10/2012 02:15 PM, Steve Doerr wrote:

given freedom of choice?

This is getting way off-topic, but...

I know it is hard to accept for a lot of people, but the more people you
put in a smaller space the less freedom of choice you have. For an
example you might understand given your previous reaction: Look at how
many people living on Manhattan (NY) own a car.



Nope, no idea what you're getting at here.

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

Re: [OSM-talk] near by

[Alan Mintz]

I didn't see the original post, so pardon me if I'm off-target.
I wanted to mention that, when working with "small" distances
and areas, I generally use the geo formulas once to calculate the
distance/degree ratios for latitude and longitude at one point*, and then
just convert other nearby lat/lons to relative distances with pythagoras.
It's far less computationally intensive, and good enough for many
purposes, including finding the closest object, smoothing ways, getting
approximate bearings, etc.
For example, at 34 deg lat, latitude is 110922.416 m/deg and longitude is
92384.593 m/deg.
At 33.5 deg lat (55 km south), lat is 110913.401 m/deg (0.008% less) and
lon is 92922.354 m/deg (0.6% more).
Using a traditional, computationally expensive formula, the distance
between first point A(34.1, 120.0) and second point B1(33.9, 120.2) is
28871.232 m. Using the constants for 34 deg lat above and pythagoras, you
get dY=22184.483 m and dX=18476.919 m. Diagonal distance d = (dY^2 +
dX^2)^0.5 = 28871.228 m (almost exactly the same).
For a second point B2(34.35, 120.15), the distance A-B2 using the
expensive formula is 30984.896 m. Using the 34 degree factors, it is
31000.353 m (error of 0.05%).
For a second point B3(34.6, 121.3), the distance A-B3 using the expensive
formula is 131838.294 m. Using the 34 degree factors, it is 132287.371 m
(0.34% error, even for such a large distance from the reference
point)
If you don't care about the actual distance values, just their relative
sizes, you can drop one more multiplication from the calculation by
determining the ratio of the lat m/deg to the lon m/deg factors, then
scaling the latitude diff by that factor and feeding the result, along
with the longitude diff, to pythagoras:
For the factors for 34 degrees above: latitudinal degrees are 1.200659x
as long in meters as longitudinal degrees. So, multiply dY (change in
lat) by this ratio and then apply pythagoras to get a mythical unit (call
it foo) value.
For A-B1, dY=0.2*1.200659, dX=0.2, d=0.312511 foo.
For A-B2, dY=0.25*1.200659, dX=0.15, d=0.335558 foo. This is 1.0737x
A-B1. Note that this is the same ratio as the distance values calculated
above (31000.353/28871.228).
For A-B3, dY=0.5*1.200659, dX=1.3, d=1.43192 foo. This is 4.5820x A-B1.
Note that this is the same ratio as the distance values calculated above
(132287.371/28871.228).

And these are all relatively long distances. When you're looking for the
nearest bus stop, intersection, etc., these approximations work quite
well. At higher latitudes, accuracy starts to decrease, but is still
within 1% out to 10s of km at 60 degrees lat.

* I don't recall the basis for these. They seem to come quite close to
traditional calcs like
http://www.ngs.noaa.gov/cgi-bin/Inv_Fwd/inverse2.prl.
It's possible (even likely) that some of the constants in the main
formulae are geoid-dependent - I've only worked with this using the GRS80
spheroid (for WGS84). $nMidLat is the latitude of interest.
$cnPi = 3.1415926535897932;
$cnSphA =
6378137.0;#
Equatorial radius in meters (GRS80/WGS84)
$cnSphB =
6356752.3141; #
Polar radius in meters (GRS80/WGS84)
$cnSphF = ($cnSphA - $cnSphB) /
$cnSphA;#
Flattening factor
$cnSphCDeg = ($cnSphA * $cnPi) / 180.0; # Meters per
1 degree longitudinal arc at 0 latitude
$nMidLatRad = $nMidLat * $cnPi / 180.0;
# Horizontal meters per degree:
$gnHMult = (1.0 + ((sin($nMidLatRad) ** 2.00362) * $cnSphF)) * $cnSphCDeg
* cos($nMidLatRad);
# Vertical meters per degree:
$gnVMult = $cnSphCDeg * 0.993307 * (1 + (3.018996 * (sin($nMidLatRad) **
2.00985) * $cnSphF));

At 2012-05-09 06:48, Ramiro Cosentino wrote:
Re all,
I've found a solution which works for me. It's basically an
implementation of the Haversine function for ruby taken from here
http://www.esawdust.com/blog/gps/files/HaversineFormulaInRuby.html
There is another one I haven't tried here:
https://github.com/almartin/Ruby-Haversine
The only drawback is that I got to fetch all the db records which are
around 500 and apply haversine distance to each compared against users's
current location (which is provided by the phone).
Thanks everyone for the input! It really helped me find the right
direction, or at least reasonable.

--
Alan Mintz 



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