Brainstorming
400px|thumb 400px|thumb This article is about internal brainstorming for the NAVIT crew. So don’t judge about other peoples entries, dare to be crazy! Ignore the order of items, keep it clear and show us your mind :)
Presence
How do you feel about the current situation in navit? What works well, what not?
good
is highly customizable!
TTS
offline maps working!
we offer really every part of the world
daily update! Jesus!
not good
Map style issues (visual clutter, styles not usefull for spec. scenarios)
Search is not failure-resistant and could be easier to use
adding external POIs is hell
no good deployment currently
only IRC is used for communication (bad logging and asynchronous communication)
mostly cp15 seems to be active in development
unclear where to get maps with newest maptool/newest data
make use of only few OSM POIs
maps need to get installed manually
many pages provide OSM Navit binfiles, sometimes they are broken or incompatible
Future
What do you expect from the upcomming year? What is important to you?
Recommendations
What kind of (abstract) decisions should we take that should be reflected in the roadmap?
splitup navit.xml to become easier to maintaine and to customize by installers (e.g. settings = deviceclass x platform x defaults)
and/or allow overriding global default preferences with users’ navit.xml defining only the customized bits
should allow configuration within the GUI
support more sensors (Ant+, ODB2, eCompass, altimeter, TMC, LCD brightness, buzzer, …)
allow external speech wavepacks (e.g. german Frederik Freiher von Furchensumpf, Das Känguru, Dosenfischer, …)
make use of more standard formats as KML, GPX, WMS, …
let Users help to improve routing, by offering an online webservice, where you can start routing and say if the results are good enough/suggest better routes
make use of terrain data for rendering (hill shading, contour lines, …) and routing (esp. eco-mode for electric vehicles)
navit should be ready to use after installation
take care of left/right handed traffic (for speech and turns)
add internal multilang context help
try to detect automatically as much configuration options as possible (e.g. GPS port, …)
OSD rendering = Widgets x Layouts (Container+relative config, …) x Skins x Colouring (decouple OSD layout from UI language, Hotkeys and resolution)
Antialiased rendering
make menues simplier and more useful (e.g. #1 search target, search POI, …)
allow routing profiles to be tolerant for rules of the road (e.g. bikers can use oneway roads in opposite direction, bikers can use footways as well)
GUI/interaction should be more l game console style, to be easy to use on tap devices and min button devices as well
display of online resources, as weather (openweather.org, current fuel costs, FON WLAN hotspots, IGO8 traffic surveillance…)
predict road conditions (e.g. Ice warning at very low temperature+heavy wind+bridges, low fuel / fuel station warning)
allow complex addons as drivers logbook, “follow me” mode for multiple cars, OSMbugs, Facebook, …
store user profile (age -> usability, weight -> fitness for biking, …)
download store for offering custom point/track packages prebuild e.g. FON wifi accesspoints, tracks by portals, …
drop propritetary map formats which can’t be supported on the long term (garmin, marcopolo)
allow export/import of the bookmark file without root access, to save the bookmarks when changing the device
provide a collection of navit.xml folder paths for different devices/manufacturers
review and optimize the menu structure to have day-to-day tasks on the main menu
aggressive bug triaging
become more friendly to new designers, … (docs, easy deployment via catalogue, …)
make it easier to submit bugs (explain openid usage, trac cleanup, ….)
deploy ready to use packages/installers (platform settings, basemap, …)
establish a testing process (maybe semi-automated and with manual checks for specific devices/platforms)
use distributed VCS to allow coding/submitting even when offline
provide synthetic changelog
embedd more metadata in maps (date of build, version of maptool, author, who converted, …)
deploy a basemap (show that navit works, even if not ready to use)
OSD/rendering/map style resolution/orientation independent
rendering = data x local styling (language, …) x scenario styling (car, hiking, …)
map style should be integrated in day light map style and simplified
tasks
You wish specific steps and tasks on the implementation to move forward?
rename config options to reflect the actual meaning and let them differ for users (e.g. vehicle active vs. enabled, profilename->name, …))
unify config datatypes (e.g. vehicle follow=yes but active=1 :( )
GPS signal quality
allow display of multilanguage names e.g. “München (Munich)”
navit should display more informations aboud it’s installaton, as everything changs quickly (svn version, build with, build by, which plugins installed/enabled, map details, …)
change to something that explains, that it holds gps config
make vehiceprofile flags human-readable
routing make use of official international bike route
routing make use of turning restrictions
cleanup repository (/xpm -> /svg, seperate icon folders, remove old/redundant files, …)
define OSD via a SVG mask and relative alignment
make OSD controls more abstract (e.g. a compass) and let them skin seperately
create platform testsuites
introduce abstraction level in map design (e.g. text_size, local_highway_colour, …) to make it easy to use on different devices in different countries
OSM boundaries should be used -> portal to create stable boundary poligons
OSM streets should be linked to places
split binfile and map style in layers (make runtime processing faster by searching less material even on low res hardware, different generalisation strategies e.g. for buildings, …)
POI icons for brands as superstores or fuel stations
introduce platform specific map vars (to finetune map style e.g. map_density=countryside)
redraw map, even when dragging
spec. platforms:
flip screen on iPhone/Android
NOT
What should NAVIT never support or which way we don’t like?