| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
* 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?
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
