| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
* 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.
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Note: the simpler filtering results in bigger disk space required.
But we cannot filter unknown streets early anymore, as they may be
required for polygon processing
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
We're getting close. Finally processed map of Oberbayern, Germany
without any issues. Renders nicely on Qt5. Nedds still some hacks in
maptool as I did not understan everything properly. Parts of maptool are
rather hacky, aren't they?
|
