custom render view: Low detail car navigation only

324 views
Skip to first unread message

Harry van der Wolf

unread,
Jun 5, 2013, 2:01:33 PM6/5/13
to osm...@googlegroups.com
Hi,

Another render template for a specific map view. I created this render template for myself a couple of weeks ago as I wanted an uncluttered interface. The normal default render and the high-detail-topo render (by Adam Szalapata) are nice for hiking (I really like the high-detail for hiking), but I don't like them for car navigation. They are far too cluttered especially on smaller sized displays.

So I created a new one which I called car_navigation_low_detail and of course it is completely derived from the default render, so credits go to the original creators.
As we had some discussions in the past few days about the map layout  and it being "cluttered", I decided to share my template (for what it's worth). If you like it, be happy, and otherwise delete it.
(If you have a very fast phone/tablet you probably might want to stick to the default or high-detail map views.)

From the remarks in the top of the file (which I put there myself today):
- Low detail map specifically for car navigation
- Complete replacement of default render, not overlay on top of default render (makes it slightly faster)
- Slightly different colors for roads and especially less colors
- other routeColor
- motorway junction numbers in favor of motorway junction names
- No shaders
- residential, unclassified, pedestrian roads only at higher zoomlevels and with smaller strokewidths
- No footpaths, cycletracks, tracks (e.g. anything not suitable for cars is not displayed)
- No building outlines, no house numbers. building names are displayed
- No barriers, power structures and most man made constructions
- Almost all POIs one zoomlevel higher. When navigating by car it's not necessary to see them from low zoom levels
  only fuel and a few more at original level
- some buildings and POIs (lighthouses, etc) which are very convenient for orientation when hiking/cycling, were visible at lower
  zoom levels. They have been set back to original as they are not relevant for car navigation

Note that I created a complete render template and not an overlay template like the other templates.  My template replaces the default template, instead of extending/modifying it on top of the default.
This makes my template marginally/slightly faster then the default template (0-15%) as it doesn't have to render as much detail, and it makes it 20-80% faster then the high-detail-topo render (due to the number of details and due to the fact that it is an overlay template).
On less CPU-powered phones this helps.

I'm not completely happy yet as a feature I would really like is a POI filter for what's being displayed on the map, not only for searching.  This would make it less cluttered.
And secondly: during navigating the "cursor" is centered on the screen. I would prefer to have it it on 1/3 of screen space from "where you come from", with 2/3 of screen space in the direction "where you are going to" (or 2/5 versus 3/5), combined with a slightly higher zoom level.
Meaning:
not: from ------>------ to
but: from ---->-------- to
This will give you more "anticipating time" for what is coming next. I think this makes it a little safer.

(now that I mention my wishes: I will file 2 feature requests)

Harry
car_navigation_low_detail.render.xml

Fred

unread,
Jun 5, 2013, 2:26:35 PM6/5/13
to osm...@googlegroups.com
It looks really nice!
I will love it for driving. Thank you! :)

Lg Fred

Victor Shcherb

unread,
Jun 5, 2013, 4:37:49 PM6/5/13
to osmand
Don't you want to put some screenshots :)

And yes, request to have something like <cancel> tag for rendering engine is in progress.

Victor




Harry

--
You received this message because you are subscribed to the Google Groups "Osmand" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osmand+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Hardy

unread,
Jun 5, 2013, 6:51:00 PM6/5/13
to osm...@googlegroups.com
Hi Harry,
 
havn't looked at your renderer yet, but 2 remarks on topics you mention:
 
- Regarding customizeable POI (minzoom) filters: Why don't you try and implement them in some fashion, I think it should be completetly possible in an independent renderer like you apparently created. You would just have to think of proper POI groupings (if desired, e.g. similar to the icon color categories we have), and create one or more switches. My concern is complexity if you chose to have too many categories/switches, So the key would be to find a suitable compromise between customizeability and handling, I would hate to make my default scheme more complex,because I think many users find OsmAnd too complex already and rather want more "one size fits all" settings. But in a separate renderer you youd certainly play with that .. :-)
 
- Regarding your remark on the "cursor centeriing": Not sure if you have noticed, but what you want actually makes sense primaily if you chose the map orientation according to your direction of motion, and that is exactly where we have implemented it as you want, if I read you correctly. It makes less sense if you have your map fixed to "north is up" or "according to compass", because these views are mostly used for "conventional" map viewing (north is up), or hiking/pedestrian orientation (compass mode), both are more isotropic (with no preferred direction), if you know what I mean. Hence for these 2 modes the cursor is in the map center. You can play with it by repeatedly clicking on the compass widget on the map screen.
 
Best regards,
Hardy

 

Harry van der Wolf

unread,
Jun 6, 2013, 4:35:29 AM6/6/13
to osm...@googlegroups.com
Hi,

2013/6/6 Hardy <hm.gg...@gmail.com>

Hi Harry,
 
havn't looked at your renderer yet, but 2 remarks on topics you mention:
 
- Regarding customizeable POI (minzoom) filters: Why don't you try and implement them in some fashion, I think it should be completetly possible in an independent renderer like you apparently created. You would just have to think of proper POI groupings (if desired, e.g. similar to the icon color categories we have), and create one or more switches. My concern is complexity if you chose to have too many categories/switches, So the key would be to find a suitable compromise between customizeability and handling, I would hate to make my default scheme more complex,because I think many users find OsmAnd too complex already and rather want more "one size fits all" settings. But in a separate renderer you youd certainly play with that .. :-)
 
 
It's not the minzoom as such using a groupfilter and a (possible?) renderingproperty for specific POI sets. Although I will definitely look at that as well.
What I mean is that we do have POI filters when searching. When you apply one you only search in that filter.
It would we nice when this same POI filters could be used for display, not depending on minzoom/maxzoom values.
In other words: If I select the POI filter of my choice, I only want to see those POIs and not all the other ones.
When driving a long road from home to wintersport destination or to another "far away" holiday destination, I only like to see e.g. fuel, first-aid, garage, restaurant, fast-food POIs and toll-boots perhaps (remember that I like an uncluttered map ;) ).
When on holiday and making a day trip, I'm interested in "sight-seeing" items, like the tourism POI filter, and no other pois.
When walking in a city I want to see tourism, historic, wikipedia (in osmand+), parkings and restaurants, and nothing else.
 
Search POI filters and Display POI filters should (preferably) be separate criteria (when possible. To start with, and to be able to implement it more easily they can be the same of course)
When navigating, be it by car, bicycle or on foot, you search/select a POI (a parking for your car) and then your destination is automatically on the map even if it is not in your selected POI filter for display (for example tourism & wikipedia for a city trip) .
The POI filters as such already exist. I think it is an easy implementation to create such a POI filter for display on the map: something like "IF POI:fuel == true THEN display". I think that (long) IFs section already exists as the Search works with it as well. (But it's a terribly boring action to implement as there are so many POI categories/types.)
 
 
- Regarding your remark on the "cursor centeriing": Not sure if you have noticed, but what you want actually makes sense primaily if you chose the map orientation according to your direction of motion, and that is exactly where we have implemented it as you want, if I read you correctly. It makes less sense if you have your map fixed to "north is up" or "according to compass", because these views are mostly used for "conventional" map viewing (north is up), or hiking/pedestrian orientation (compass mode), both are more isotropic (with no preferred direction), if you know what I mean. Hence for these 2 modes the cursor is in the map center. You can play with it by repeatedly clicking on the compass widget on the map screen.
 
Really?
I thought it was but I have been using the 1.4beta the last two days with navigation using "map orientation->To direction of movement" (I always use that one in the car), but I had the idea that it was centered, and my visual memory is so short that I can't remember for certain how it was in 1.3, 1.2.1 and 1.1.x.
I will check very carefully the coming days.
 
If I'm wrong I will get to my knees and apologise (apologize if you're american) :)
 
Harry
 

Harry van der Wolf

unread,
Jun 6, 2013, 7:11:18 AM6/6/13
to osm...@googlegroups.com
Regarding the POIs filter for display: It's already implemented.
 
I did a very quick small test and for that reason I first switched off the POIs (for the very first time I think), to see if my renderingproperty(1) would work. Well: it doesn't. You get the option nicely in your configure screen options, but when POIs are switched off, such a renderingproperty doesn't enable it.
 
However, after that test I switched on the POIs again. At that very moment I CAN select a POI filter, also a personal defined one, and it does work fine. So you quickly switch it off and then switch it on and select another (personal) POI filter.
 
I will add a few lines about this to the Wiki as that section (http://code.google.com/p/osmand/wiki/HowToFilterPOIs) more or less mentions the POI filter for the search options but not the display options. Maybe I'm the only dumbo for whom this was not obvious, but in case another dumbo shows up we can redirect him/her.
 
Harry
 
(1): <renderingProperty attr="POIs_Car_navigation" name="POIs_Car_navigation" description="show POIs related to car navigation"
  type="boolean" possibleValues=""/>

Hardy

unread,
Jun 6, 2013, 10:32:14 AM6/6/13
to osm...@googlegroups.com
Unless I am mistaken, the existing POI filter works for the POI OVERLAY, i.e. the orange-highlighted circles, but NOT the POI icons displayed in the vector maps directly.
 
But we can probably work on using these POI filters for both, in a way combining the 2 features via the existing selection mechanism. That's what I meant by "play with renderer switches" somewhere above.
 
Please note that the POI overlay is rather minzoom-independent, while the current minzooms for POI icons in the map itself follows some logic (you will see from looking at my default renderer code), it is likely also explained in the initial comment, too: I distinguish between "street corner" items, building-size items, larger facilities like universities, libraries, etc. So both mechanisms have their logic and purpose, but we could maybe find a common and useful way to make both customizeable a bit.
 
Best,
Hardy
 

Harry van der Wolf

unread,
Jun 6, 2013, 12:55:33 PM6/6/13
to osm...@googlegroups.com


2013/6/6 Hardy <hm.gg...@gmail.com>

Unless I am mistaken, the existing POI filter works for the POI OVERLAY, i.e. the orange-highlighted circles, but NOT the POI icons displayed in the vector maps directly.
 
Yes, I already came to that conclusion as well.
 
 
But we can probably work on using these POI filters for both, in a way combining the 2 features via the existing selection mechanism. That's what I meant by "play with renderer switches" somewhere above.

I do understand it now after I came to the first discovery above :)
 
 
Please note that the POI overlay is rather minzoom-independent, while the current minzooms for POI icons in the map itself follows some logic (you will see from looking at my default renderer code), it is likely also explained in the initial comment, too: I distinguish between "street corner" items, building-size items, larger facilities like universities, libraries, etc. So both mechanisms have their logic and purpose, but we could maybe find a common and useful way to make both customizeable a bit.
 

 That would be nice. There are some other apps that do feature this.
Another option could be from the MapCreator to create two maps: One real map without POIs, and one map only containing POIs. These two maps could be put into one zip (or multipart zip), and upon download and unpacking you would have a map with e.g.  <country>_<continent>_2.obf and a <country>_<continent>_pois_2.obf.
You could even make this two downloads, for those only wanting a map and not needing the POIs, but I don't think that's a likely occasion.
Having them in separate obfs might simplify the implementation. More apps, both OS and commercial, do it that way.

Harry

Harry van der Wolf

unread,
Jul 26, 2013, 9:23:03 AM7/26/13
to osm...@googlegroups.com
During my holiday I updated my car navigation render template.

From my additional comments in the header (followed by V1 comments:
<!--    HvdW, 2013-07-13/15, V2
        - Remove unused filters, values, some remaining shades, etc.
        - Add road atlas colors for motorway & trunk (Copied from Hardy's Tourist view). Routecolor back to original for contrast reasons.
        - Removed some errors.

        HvdW, 2013-06-04, V1
        - Low(er) detail map specifically for car navigation.
        - replacement of default render, not overlay on top of default render (makes it slightly faster).
        - Slightly different colors for roads and especially less colors.
        - other routeColor.
        - motorway junction numbers in favor of motorway junction names.
        - No shaders.
        - residential, unclassified, pedestrian roads only at higher zoomlevels and with smaller strokewidths.
        - No footpaths, cycletracks, bridleways, tracks (e.g. anything not suitable for cars is not displayed).
        - No building outlines, no house numbers. building names are displayed.
        - No barriers, power structures and most man made constructions.

        - Almost all POIs one zoomlevel higher. When navigating by car it's not necessary to see them from low zoomlevels
          only fuel and a few more at original level.
        - Some buildings and POIs (lighthouses, etc) which are very convenient for orientation when hiking/cycling
                  were visible at lower zoomlevels. They have been set back to original as they are not relevant for car navigation.
    -->


Harry


2013/6/6 Harry van der Wolf <hvd...@gmail.com>
car_navigation_low_detail.render.xml

Chris

unread,
Dec 21, 2013, 4:48:05 PM12/21/13
to osm...@googlegroups.com
Harry,
I was looking forward to a less crowded map myself - especially when on the motorcycle. I think your solution it's what I was searching for.
In some cases and mainly in a city centre there so many POIs that the roads almost disappear. Unfortunately I do not have your skills to create a template and I dont even know how to install yours. If possible can you please tell me how to install it.
I pressume it will work on UK offline map (possibly I am showing my ignorance :-) )
Many Thanks
Chris

Harry van der Wolf

unread,
Dec 22, 2013, 6:43:19 AM12/22/13
to osmand
Hi,

Since then I made a new one.
The first few ones were designed as a completely stand-alone render. That was the "car_navigation_low_detail" render.

The one I'm using now is called "CarNav". It is based on the default render but hides some items at some levels. I switched to using the default render as basis for my CarNav render as some options and functionality in the default render change over time.
I also switched to a slightly different colour scheme for roads and urban areas.

The "CarNav" has two options under menu-->Configure screen in the map view:
- Show buildings and housenumbers
- Show (foot)paths, cycleways, tracks, etc.

The "car_navigation_low_detail" is "cleaner" then the "CarNav" version as I removed more options in that one.

Connect your phone to your pc. Copy the render files into the osmand/rendering folder on your phone.
Note that the double extension .render.xml is necessary. Otherwise OsmAnd does not recognise the files.
In your map screen go to menu->configure screen->map style.

Note that I don't use OsmAnd anymore for car navigation as it has become way too heavy in the last versions (>6.x). I only use it for cycling and hiking, as speed is much lower there and therefore map updates need less performance. (I mention this only to say that I don't maintain my own car navigation renders anymore which is a real pity as I still prefer OsmAnd. However, it is the only car navigation app that is CPU/GPU-wise too heavy for my phone. All other car navigation apps work fine.)


Harry


2013/12/21 Chris <ch...@stavrinides.net>

--
CarNav.render.xml
car_navigation_low_detail.render.xml

Chris

unread,
Dec 22, 2013, 9:55:23 AM12/22/13
to osm...@googlegroups.com
Thanks Harry
The "car_navigation_low_detail" is perfect for me. Map is much cleaner and easier to look at now.
I understand what you mean by being too heavy - It stretches my Blackberry Z10 to its limit but OsmAnd its perfect for saving motorcycle rides or create new routes for sharing and following.
Usually I record a route using TripLogger (it uses minimum resourses, its fast enough for a motorcycle, running in the background and minimum use of battery) and export the GPX file to OsmAnd. I found OsmAnd not reliable (unless I am doing something wrong) in recording tracks as I had a few dissapointing recordings of straight lines.

Again many thanks for your help, appreciated
Rgds

Chris

On Wednesday, June 5, 2013 7:01:33 PM UTC+1, Harry van der Wolf wrote:
Reply all
Reply to author
Forward
0 new messages