[talk-au] Optimising map rendering for recreational use

Nathan Van Der Meulen natvander at yahoo.com
Thu Nov 1 22:47:30 GMT 2012


As a traveller, I can certainly see merit to "pushing" a certain road to being rendered in a specific way.  Most vector maps (OSM, Google, Apple, Navteq etc etc) have a big empty space in the centre.  IMHO it would be very handy to be able to see some of these tracks rendered at a much higher (alt.) zoom than current, yet still see their road classification (suggestions for up-classing a track won't work as it may well suggest that a 4wd track like the French Line or Gunbarrell is a decent road!).  Given that many of these tracks are 500-100km in length, the current zoom level you need to be at to see them makes visualising them a chore.

It certainly would be handy if OSM rendered unpaved roads differently to paved roads.

Nathan




________________________________
 From: "talk-au-request at openstreetmap.org" <talk-au-request at openstreetmap.org>
To: talk-au at openstreetmap.org 
Sent: Thursday, 1 November 2012 9:41 PM
Subject: Talk-au Digest, Vol 65, Issue 4
 
Send Talk-au mailing list submissions to
    talk-au at openstreetmap.org

To subscribe or unsubscribe via the World Wide Web, visit
    http://lists.openstreetmap.org/listinfo/talk-au
or, via email, send a message with subject or body 'help' to
    talk-au-request at openstreetmap.org

You can reach the person managing the list at
    talk-au-owner at openstreetmap.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Talk-au digest..."


Today's Topics:

   1. Re: Optimising map rendering for recreational use (Li Xia)
   2. Re: Rendering hint suggestions (Stephen Kelly)
   3. Re: Rendering hint suggestions (Li Xia)
   4. Re: Optimising map rendering for recreational use (David Bannon)
   5. Re: Adelaide Metro using OpenStreetmap/OpenTripPlanner
      instead of Google Transit (Daniel O'Connor)


----------------------------------------------------------------------

Message: 1
Date: Thu, 1 Nov 2012 19:47:03 +1100
From: Li Xia <lisxia1982 at gmail.com>
To: Ben Kelley <ben.kelley at gmail.com>
Cc: OSM Australian Talk List <talk-au at openstreetmap.org>
Subject: Re: [talk-au] Optimising map rendering for recreational use
Message-ID: <ADE71F15-A95D-4700-894E-E8599B8E1AA9 at gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Importance is of most interest. In regional areas where density is much lower, rendering lower class roads earlier on in the zoom level would improve the usability of the map much more.

Li.


On 01/11/2012, at 5:32 PM, Ben Kelley wrote:

> You can change how mapnik renders by defining different styles for different zooms.
> 
> Essentially with render hints you are saying that you would like this way to look like a different type of way. If this does not map to some verifiable attribute of the way then it becomes your preference.
> 
> Presumably there is something about the road that leads you to want it to look differently. Why not tag the physical (and verifyable) thing that is different, and change your style definition when you render it?
> 
> Is it the surface? The importance? The width? The destination?
> 
>   - Ben.
> 
> On Nov 1, 2012 5:13 PM, "Daniel O'Connor" <daniel.oconnor at gmail.com> wrote:
> 
> What do you guys think?
> 
> It's non trivial to do it this way, but:
> Define a relationship between zoom level and number of ways/nodes within the bounding box
> Sort the ways in a weighted fashion - roads first, land boundaries second, etc
> Zoom level max, with 10 nodes to render: well, that should likely render everything
> Zoom level max - 1 with 1 billion nodes to render - roads only
> To actually set up the balance between zoom and what to render would be hard, but I think that's a better approach than render hints. Alternatively, after implementing it, you could add a 'render weighting/interest' attribute to a lot of ways, which would be like a render hint but also suitable for other purposes - ie: routing or search.
> 
> 
> 
> _______________________________________________
> Talk-au mailing list
> Talk-au at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-au
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-au/attachments/20121101/0b3fcc68/attachment-0001.html>

------------------------------

Message: 2
Date: Thu, 1 Nov 2012 18:49:07 +1000
From: Stephen Kelly <steve at sjk.net.au>
To: John Smith <deltafoxtrot256 at gmail.com>
Cc: Li Xia <lisxia1982 at gmail.com>, OSM Australian Talk List
    <talk-au at openstreetmap.org>
Subject: Re: [talk-au] Rendering hint suggestions
Message-ID:
    <CAN3=Ykz+dP45cAi++hSDHkRf+d2WEvGXuKi4g7VQg-voZ1Z97w at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

most renderers have smarter algorithms than just get rid of every 'x' nodes
- they do it more like- reduce the number of nodes so that the feature
deviates by less than 'x' distance / angle


On Thu, Nov 1, 2012 at 6:46 PM, John Smith <deltafoxtrot256 at gmail.com>wrote:

> On 1 November 2012 19:32, Li Xia <lisxia1982 at gmail.com> wrote:
> > The issue is one of performance, and sorting data no the fly is an
> expensive operation.
>
> there is already apps that do off line rendering, they pre-process
> data, and usually drop the number of nodes to 1/10th etc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-au/attachments/20121101/c99f012c/attachment-0001.html>

------------------------------

Message: 3
Date: Thu, 1 Nov 2012 19:55:03 +1100
From: Li Xia <lisxia1982 at gmail.com>
To: John Smith <deltafoxtrot256 at gmail.com>
Cc: steve at sjk.net.au, OSM Australian Talk List
    <talk-au at openstreetmap.org>
Subject: Re: [talk-au] Rendering hint suggestions
Message-ID: <ABB9329A-91B7-4DEE-B855-6A490A085E37 at gmail.com>
Content-Type: text/plain; charset=iso-8859-1

Other than skobbler, which is more for turn by turn, i've never seen anything that can render a regional map to the standard we are chasing.

Nodes are already been reduced dynamically by marking each node at compile time with a level of importance. 

Issue isn't reducing nodes, it's more related to at which zoom level each road class is been rendered. Issues lies in the difference in density. A config that works well for metro areas doesn't work in regional areas.

Li.


On 01/11/2012, at 7:46 PM, John Smith wrote:

> On 1 November 2012 19:32, Li Xia <lisxia1982 at gmail.com> wrote:
>> The issue is one of performance, and sorting data no the fly is an expensive operation.
> 
> there is already apps that do off line rendering, they pre-process
> data, and usually drop the number of nodes to 1/10th etc




------------------------------

Message: 4
Date: Thu, 01 Nov 2012 19:46:39 +1030
From: "David Bannon" <dbannon at internode.on.net>
To: talk-au at openstreetmap.org
Subject: Re: [talk-au] Optimising map rendering for recreational use
Message-ID:
    <e50e8c6f54f8233861c1a2bf256b56e2fdfe2152 at webmail.internode.on.net>
Content-Type: text/plain; charset="utf-8"

?
Li, another complication worth thinking about. In theory, when we map
a road, the highway tag needs to relate to the purpose of the road
rather than the condition. This is a topic that has been under
discussion for the last week or so. And renderers really only seem to
be interested in the highway tag, ignore tags such as 4wd_only and
tracktype (for other than highway=track).

So, for example, roads such as the Tanami track or Plenty Highway are
technically, primary roads. And therefore rendered at quite a broad
zoom level. I got all upset about this as I am worried that
potentially visitors see a nice thick line and assume its a nice road.
(In fact they are great roads but not for the ill equipped!).

I have been pushing the idea if we are to stick to the politically
correct idea that highway is about purpose and not condition, then we
need a reliable way to warn people reading the maps AND importantly,
people building rendering engines what the condition might be.

Please see the discussion page on
http://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines and
http://wikiopenstreetmap.org/wiki/Key:tracktype

I have suggested extending tracktype to, a) have additional levels of
difficulty and b) clarify that this grading really does apply to all
roads, not just highway=track

I do think that this might be a better way to achieve what you want
too. But the real issue is the mainstream renders and the routers
won't think about it unless its widely adopted and used. As they say
in the ALP, disunity is death !

David

----- Original Message -----
From: "Li Xia" 
To:
Cc:
Sent:Thu, 1 Nov 2012 15:01:11 +1100
Subject:[talk-au] Optimising map rendering for recreational use

Hey everyone, have an idea about map rendering and want to get your
thoughts.
One of the challenges is in rendering a useful map for recreational
use is displaying roads, tracks, trails and to some degree water lines
at appropriate zoom levels in more remote regions where the density is
lower compared with urban regions. 
  In my opinion, most map service online services or offline vector
engine experience the same issue. Here are some illustrations of the
issue, by comparing Google / OSM / Raster map of the same region:

Google [1]  
OSM [2] 
Raster map [3] 
As you can clearly see, at that zoom level, there's no deal on either
OSM or Google maps, where as the raster map is useful. yes you can
zoom in on Google or OSM, but with a smaller viewing port, orientation
is more difficult and you loose that overview which is try handy for
trip planning. 
By using a tag specific for rendering purposes, this issue can be
overcome. Rendering engines can take advantage of these tags to
"optimise" rendering of various regions. 
The tags are fairly self explanatory. By tagging a road with
render_as:trunk, this feature can be rendered at the same zoom level
as a trench road. Each class of road will have it's own tag so if a
highway:territory should be rendered at the same zoom level as a
primary, then tag render_as:tertiary. 
What do you guys think? 
Cheers? 
Li.  


Links:
------
[1]
http://www.mud-maps.com/li_temp/1211/Screen%20Shot%202012-10-25%20at%204.42.31%20PM.png
[2]
http://www.mud-maps.com/li_temp/1211/Screen%20Shot%202012-10-25%20at%204.42.26%20PM.png
[3]
http://www.mud-maps.com/li_temp/1211/Screen%20Shot%202012-10-25%20at%204.42.22%20PM.png

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-au/attachments/20121101/101aa6df/attachment-0001.html>

------------------------------

Message: 5
Date: Thu, 1 Nov 2012 21:11:34 +1030
From: "Daniel O'Connor" <daniel.oconnor at gmail.com>
To: Alex Sims <alex at softgrow.com>
Cc: talk-au at openstreetmap.org
Subject: Re: [talk-au] Adelaide Metro using
    OpenStreetmap/OpenTripPlanner instead of Google Transit
Message-ID:
    <CAJsZyFA837MkNDC7xBMcxKuYN=aeBUK7ybj_1tXabPdOqMSXxg at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Thu, Nov 1, 2012 at 5:08 PM, Alex Sims <alex at softgrow.com> wrote:

> Adelaide Metro, the umbrella brand for public transport in Adelaide on
> their new (beta) website at
>
> http://www.adelaidemetro.com.**au/ <http://www.adelaidemetro.com.au/>
>
> are using OpenTripPlanner and OpenStreetmap for journey planning. Nice to
> see OpenStreetmap getting more, albeit unacknowledged exposure.
>

Are they pushing data into OSM? Or do we know if the installation has data
services available? (Good to see the bus stops are URIs!)

I remember approaching them several years ago, asking about data extracts
of timetables/stop locations/etc to do mashups - I met with them, but I
felt it went poorly at the time.

It's interesting to see this as basically an about face!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-au/attachments/20121101/e726bf9f/attachment.html>

------------------------------

_______________________________________________
Talk-au mailing list
Talk-au at openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-au


End of Talk-au Digest, Vol 65, Issue 4
**************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-au/attachments/20121101/6151d639/attachment-0001.html>


More information about the Talk-au mailing list