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: "[email protected]" <[email protected]>
To: [email protected] 
Sent: Thursday, 1 November 2012 9:41 PM
Subject: Talk-au Digest, Vol 65, Issue 4
 
Send Talk-au mailing list submissions to
    [email protected]

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
    [email protected]

You can reach the person managing the list at
    [email protected]

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 <[email protected]>
To: Ben Kelley <[email protected]>
Cc: OSM Australian Talk List <[email protected]>
Subject: Re: [talk-au] Optimising map rendering for recreational use
Message-ID: <[email protected]>
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" <[email protected]> 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
> [email protected]
> 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 <[email protected]>
To: John Smith <[email protected]>
Cc: Li Xia <[email protected]>, OSM Australian Talk List
    <[email protected]>
Subject: Re: [talk-au] Rendering hint suggestions
Message-ID:
    <CAN3=ykz+dp45cai++hsdhkrf+d2wevgxuki4g7vqg-voz1z...@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 <[email protected]>wrote:

> On 1 November 2012 19:32, Li Xia <[email protected]> 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 <[email protected]>
To: John Smith <[email protected]>
Cc: [email protected], OSM Australian Talk List
    <[email protected]>
Subject: Re: [talk-au] Rendering hint suggestions
Message-ID: <[email protected]>
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 <[email protected]> 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" <[email protected]>
To: [email protected]
Subject: Re: [talk-au] Optimising map rendering for recreational use
Message-ID:
    <e50e8c6f54f8233861c1a2bf256b56e2fdfe2...@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" <[email protected]>
To: Alex Sims <[email protected]>
Cc: [email protected]
Subject: Re: [talk-au] Adelaide Metro using
    OpenStreetmap/OpenTripPlanner instead of Google Transit
Message-ID:
    <CAJsZyFA837MkNDC7xBMcxKuYN=aebuk7ybj_1txabpdoqms...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Thu, Nov 1, 2012 at 5:08 PM, Alex Sims <[email protected]> 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
[email protected]
http://lists.openstreetmap.org/listinfo/talk-au


End of Talk-au Digest, Vol 65, Issue 4
**************************************
_______________________________________________
Talk-au mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-au

Reply via email to