navit-project.org

In the past, we used only one single navit.xml and it was good

But in presence, it turns out, that this approach causes some problems:

• bad to edit, esp on embedded devices (size and complexity)
• distribution of addons/replacements/changes hard to realize (automatism)

So there is the idea, to split this file up, to allow an easier customization. A easy way to realize this, is to use XML inclusion that is already supported, but not really in use.

This allows us to export XML sections to seperated files, for example:

• osd.xml
• vehicle.xml
• layout.xml

while keeping the very basic settings (mapset, ...) at the main navit.xml.

One step further, we could define a include chain, that can improve settings step by step. For example the map style:

• map_default.xml - make basic objects visible and define styling/generalisation
• map_DE.xml - offer colouring for Germany
• map_car.xml - filter objects/attributes that are important for car drivers

But we need to try to realise that with examples, to see if this forward inclusion is enough, or if we need to specify vars or patch already parsed XML elements. If it works well, we can offer much better outofthebox values for all options: settings = deviceclass x platform x defaults

+1
Sounds good... the navit.xml is really big for the moment, so it isn't so easy to find the entries and edit it.

That is actually what i did.

I made my own navit.xml with just the GUI, User-OSD and roadprofiles in it.

At the End the include tag with ~/Navit/OSD/*.xml and ~/Navit/Map/*.xml .
The first includes the different maplayouts (OSM, navit-Original, Android) so whatever i downloaded and made a seperate OSM.xml, navit-original.xml and so on.
The Map directory includes a xml-file where the path to the maps is defined.
That is just for my different PCs where i use navit. F.e. on my CarPC there is a data-partition with lots of space so the map(s) are saved there; my eeePC (mobile/backup navit) has only a 4GB SSD, just enough for the system, navit and the maps are on the SD-card; my navit-vm (for testing) has only one big partition for all the stuff.
I only have to alter one file (in the Map) directory for the different PCs, the rest stays the same and alway up to date (done by a sync program).

Thanks for sharing your opinions.

user:vinYl wrote at the chat, that he had problems to use includes at WinCE. I don't expect this to be a general issue, but maybe it's a bug to resolve paths.

I started a first draft to explore how we can split, define names etc.
https://wiki.navit-project.org/index.ph ... _navit.xml

BTW, a similar technique but based on XSLT we already use in the build process:
http://navit.svn.sourceforge.net/viewvc ... avit/xslt/
IMHO this is a good stating point, but it models from the wrong direction (use some from default, some platforms patching, ...) and doesn't allow to customize at enduser side.

hi all,

usul pointed me here after I posted ticket nr 1157 on the track list. I have a similar problem as I use navit on the desktop (linux), freerunner (linux, small high resolution screen), ArchosG9 (android, medium resolution screen) and Samsung Y Duos (android, mediocre screen: 240x320...). So it is quite a task to have new osd layouts and maplayouts fitted for them all.
my suggestion is to split the xml file even a bit further and have main navit.xml which links to the others:

navit.xml
-> navit_plugins.xml (different between linux + android)
-> navit_debug.xml
-> user_navit_center.xml (just <navit center=....>)
-> navit_drawing.xml
-> user_menu.xml (one would like to have different layouts depending on the screen size = more rows, smaller icons ...)
-> user_osd.xml
-> user_vehicle.xml (including vehicle profile)
-> user_speech.xml
-> user_mapsources.xml
-> user_maps.xml

sounds like a lot of splitting up, but I think it is worth while. the easiest way to have more people become interested in navit and to provide something at a relatively low level is the map layout or the osd layout. so one could even think about a maplayout subfolder where the users just drags and drops xml.maplayouts from the wiki or a nice simple page like the planet extractor which automatically renders three different parts of a map (like city, wood, motorway, each at 2 zoomlevels) to give a quick impression how the rendering looks like and gives the user the possibility to download the style to the directory and have it activated (on restarting ?).

Yesterday I looked at osmand which in my opinion is the main alternative to navit on android (only). it has
- very nice maps (you can change them easily as well)
- a nice standard osd layout (navit osd you can configure which is great but I think navit should have a somewhat newer standard layout to attract more people)
- a good maps manager (as it allows you to update maps)
- a by far inferior offline routing engine(!) I tested this with a long route from west germany to romania. It always ran out of memory; navit managed to get the job done.

So for long routes osmand is still no option but it has a quite clean fresh starting look. If navit.xml could be altered to easily adjust the looks, have good standard looks and have "map skins" which are easy to upload and which are then automatically rendered and easy to integrate this would, at least in my opinion, attract a lot more "simple" developers.

br

robin

As I pointed out in your ticket, the whole splitup strategy is a bit more complex as we try to implement abilities to inherit and to to patch small/bigger chunks on the XML structure within subfiles. This will take some time and IMHO we should focus it on the next major release.

IMHO your splitup is a bit to fine. I see no reason to seperate the debug, speech, ... elements into seperated files. Why not thinking in platforms and bundle settings that need to be adapted by the user, some that can be set by the installer and some that should (usually) not altered but switched (as map styles, vehicles, ...)?

In general, we try to improve Navit step by step and are aware on the usability issues etc. :
http://wiki.navit-project.org/index.php/Brainstorming
But the dev team is pretty small, so we can only put the focus on smaller improvements and not doing the whole think at once.

sorry if that came out a bit too fine. I just went through the xml structure of navit.xml and each time I saw a part which was not equal either due to android and linux differences or screen resolution dependend differences I wrote it down. the approach to keep things together eg platform is certainly what I have meant. so

navit.xml would certainly contain:
- navit_plugins.xml (different between linux + android)
- navit_debug.xml
- navit_drawing.xml

and maybe also
- user_speech.xml
- user_vehicle.xml (including vehicle profile)

those I think would be good to have at the user hand (in decreasing relevance):
- user_osd.xml
- user_maps.xml
- user_menu.xml (one would like to have different layouts depending on the screen size = more rows, smaller icons ...)
- user_mapsources.xml
- user_navit_center.xml (just <navit center=....>)

I have a question regarding the website. is navit running on the server? so could we somehow have navit render a map and save it as a png. It has been quite a while since I have been programming in php, but I could try to put something together which where you could upload a map.xml have it rendered (eg as preview and once you are satisfied say publish under cc and have it displayed on the maps.preview website, which then generates the different layouts and has a download mapstyle button to get the style to your device.

best regards

robin

In general the rough file layout looks reasonable to me and is (IMHO) what we try to realize with this new approach. But again, this is scheduled for the next major release and we try currently to focus the 0.5.1 minor release, to cleanup our dev process, consolidate source and making navit more stable/reliable.
This doesn't mean that we don't want your feedback(!), but please respect that we have very limited dev ressources and so we have to put tasks into order and focus them one by one. As the 'make the visual appealing more exchangeable' is very complex (crossplattform, save redundancy, ...).

A template gallery would be very nice. As Navit has good ability for remote control via various languages, a thumbnail generator would be IMHO somehow possible. There is already a navit QA portal for checking navits routing along various routes. Maybe this would be a good starting point for such kind of developments. But I guess this becomes more complex and might need a seperated topic to dicuss this idea.

There is one thing we'll have to think about (a bit off-topic but necessary) - even if the next release is stable and available for the most common OS, the actual look and feel will be burned into users mind.
What I want so say is that changing the look (GUI and/or OSD) behavior after a major release can make users feel uncomfortable with the whole software/app.
So I guess this should be considered too.

0.5.1 is a minor release and a first step to get back to release cycle.
I'm very happy to talk to everybody about goals pros/cons etc. but please in the original post:
viewtopic.php?f=19&t=432