| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
| |
and reenable xml lint for all configurations shipped.
|
| |
|
| |
This pull request includes postal code or zip code into the town search.
|
| |
|
|
|
|
|
|
|
|
| |
* cleanup:search:Minor - Use fallthrough like the rest of the cases
* Remove fallthrough for readability
* Revert "Remove fallthrough for readability"
This reverts commit 68a78f692ebcd19b5b2ca2100e221eb8987bc71a.
|
| |
|
|
|
|
| |
* Add watch after reopen the file
vehicle_file_close(priv) disables the watch of the file.
vehicle_file_open(priv) dont re enable it. So the gps position was frozen
|
| |
|
| |
https://github.com/navit-gps/navit/pull/877
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the introduction of the multipolygon code we now have all the nice landuses in the map. However, in OSM there are some map features that are not mapped as multipolygon but just "above" the other landuses. Like poly_zoo, poly_theme_park or poly_airfield.
Current configuration causes them to be hidden by the landuses, as these are drawn after the above mentioned. OSM's Mapnik style solves the problem by drawing those feature transparent above the landuses.
This pull request does so for some map features as well causing the map to look way better.
If transparent drawing is not supported by the platform, this causes the mentioned polys to be drawn above the landuses, showing them, eventually hiding some landuse details underneath. But this looks even better than before too.
NOTE: Transparent drawing is known to work on: Qt5 (sailfish) and gtk.
NOTE: Transparent drawing is known NOT to work on SDL
Dont't know for all the others. Sombody might want to check Android? Remember #852 on comparing screenshots though.
* Fix: layout_car: draw map features transparent on top
Some map featuresa re usually not put into multipolygons, but simple
tagged "on top" of the others. So It's quite common for example to
tag "poly_airport" on top of the underlying other landuses inside the
airport. Move (some) of those elements on top of the polygon draw stack
and make them transparent. Looks way better on graphics that support
transparency. Not much is lost on those that don't.
* Fix: layout_car: differentiate meadow and farmland in color
* enhancement:layout-car:Make poly_barracks and poly_university transparent
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
tunnels transparent + mark oneway streets (#884)
This pull request adds the possibility to globally set a default for icon size of a layout.
You can now give "icon_h" and "icon_w" properties in "layout" tag. This causes navit to not use the real size of an icon but to scale it to have the requested size. Guessing prescaled icons (the name_w_h.png's of course works. Default size of 22x22px which is the default size hint on most of the svg's is used. This fixes #819.
This pull request adds the property "underground_alpha" to the "graphics" tag giving the alpha value to use as transparency if ways are flagged with AF_UNDERGROUND. This effectively renders tunnels in transparent.
This pull request adds a "oneway" tag to itemgras in layouts. Together with the enhancements of the "arrows" itemgra used for drawing the route graph one can print nice arrows on oneway roads.
|
| |
|
|
|
| |
* Rework:USERPROFILE for Windows
Use extended environment_vars array for Windows. Use ~ to provide
homedir for Windows using USERPROFILE.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#883)
* add:doc: Migrate MacOS Development page to readthedocs
* add:doc:migrate wince development to readthedocs
* Fix trailing spaces
* add:doc: Migrate windows development to readthedocs
* Fix trailing spaces
|
| |
|
|
|
|
|
|
| |
* update:doc:Migrating linux development from the old wiki
* copy-paster pages
* Finalizing
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#794)
* Adding unescape string utility and unescaping alls values in textfile attributes
* Moving coordinates_geo out of internal use in gui_internal_command.c (to coord.c)
* Moving gui_internal_escape() into generic str_escape() function in util.c
* Moving strncpy_unescape() into generic function in util.c
* Using geo coords as item name in Android contextual menu "Route Here"
* Using string escaping (for double quotes) when writing former destinations to file
* Adding new type DEGREES_MINUTES_SECONDS_BRIEF to factorize coordinates_geo()
And fixing the example strings to match what is actually output by the function
* Adding support for DEGREES_MINUTES_SECONDS_BRIEF format into coord_format
And add internal coord_format_with_sep() to specify the separator
* Fixing doxygen doc for coord_format_with_sep()
* Making coord_format() inline
* Using new factorized generic function coord_geo_format_short() instead of coordinates_geo()
* Changing single contextual window title with GPS coords on Android
* Adding string bytes length for each coord to string format, using short format in pcoord_format_short() and coord_geo_format_short()
* Using pcoord_format_short() in android
|
| |
|
|
| |
There is a "misconception" in qt5 graphics about how to draw transparent stuff causing transparent items on the map to not correctly work. This PR changes qt5 graphics to force-clear overlays on starting to draw them instead of force clearing the shape of a transparent item. While this imposes the limitation that the content of an overlay cannot be drawn in multiple runs, it allows to draw transparent stuff on the map.
Luckily I don't know of any overlay item yet that is not drawn in one run. So this seems to work OK.
|
| |
|
| |
#724 updated the navit logo, but forgot about the desktop icons used for Sailfish and maybe others.
|
| |
|
|
|
|
|
|
| |
* Updating navit logo for QT
* Adding navit icon to GTK GUI's windows, using the black and white version of the icon in GTK GUI for better readability
* Fixing memory leak in GTK geticon()
* Adding source svg for all variations of the logo (integrating to the repo, the svg logo catalog that was last posted in #436 (https://github.com/navit-gps/navit/issues/436#issuecomment-450587935)
Credits for logo design: redmusic27 and zintor
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* fix:core:refactor polygon clipping
This commit extracts the polygon clipping into its own function to be
re used for polygon with holes clipping.
* fix:core:Clip polygons with holes prior drawing.
While this helps drawing for limited graphics like SDL or WindowsCE,
it will slightly slow down on graphics that do clipping themselves like
qt5. As this is done for polygons already, we do this for polygons with
holes as well.
|
| |\
| |
| |
| |
| | |
Fix #847
Admin levels for additional countries
|
| | |\
| |/
|/| |
|
| |\ \
| | |
| | |
| | |
| | | |
Add:graphics/windows: polygons with holes for windows CE
This uses the same "hand and foot" raycasting algorithm than the SDL version does since WindowsCE lacks the fancy drawing routines of better Windows.
|
| | |\ \
| |/ /
|/| | |
|
| |\ \ \
| | | |
| | | | |
Add:graphics/sdl: Polygon with holes support.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Always use polygon with holes primitive for drawing polygons, as this
should be faster than older SDL_gfx like drawing primitives because
we do not copy the coordinates into different style buffer before
raycasting.
|
| |/ / / |
|
| |/ / |
|
| | |\
| |/
|/| |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This adds multi polygon support to navit binfile.
It uses the following attempt:
- Multipolygon "outer" polygons are converted to polygons inside the binfile map.
- Multipolygon "inner" polygons are added as attributes to the outer polygon.
- New method is added to graphics to draw polygons with "holes" (currently qt5,
gtk_drawing_area, and Windows (except CE) but at least sdl can do this as well)
Since the binfile format stays structural intact, new maps can be processed by old Navit versions, except they draw the multipolygons without their "holes",
New version of Navit can still read old maps of course.
Limitations:
- In the maps, there are multipolygons having other multipolygons as inner or outer.
These are unsupported and fail the member check. According to
https://wiki.openstreetmap.org/wiki/Relation:multipolygon these are invalid. And the
current web display cannot display them as well. See
https://www.openstreetmap.org/relation/5587300 . Don't know if this get a standard
mapping feature. Hopefully not.
- Multipolygon polygons tend to become huge. No algorithm to split them into smaller
chunks is contained. But my personal opinion is to exclude some types of polygons
from map altogether on constrained devices over not including or artificial cutting the
multipolygon ones. Btw. there are already huge traditional polygons as well.
- Processing the map required more disk space as one cannot early drop ways with
unknown tags any more, as they could be part of multipolygon. Maptools -n flag
works as expected for the final result though.
Additional changes:
- Default to 64 bit zip files on maptool
|
| | |\ \
| |/ /
|/| | |
|
| | |\ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* Add:graphics/windows: drawing polygons with holes
For all Windows except windows CE.
|
| | |\ \ \ |
|
| | |\ \ \ \ |
|
| | |\ \ \ \ \ |
|
| | |\ \ \ \ \ \ |
|
| | | | | | | | | |
|
| | |\ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Should not be neccesary.
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
This is baraindead. Lost days of computing time because getting invalid
zip files at the end because of being too big. Make 64 bit zips the
default. Neccessary for big maps anyway, and shouldn't hurt on small
files.
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Way faster because a) better cpu usage on multicores and b) multiple but
smaller hashes that scale O^2 on inserting. They are just O on reading,
so the multiple doesn't count that much. And besides that we save main
menory as we can process each hash independent.
|
| | | | | | | | | | | | |
|
