Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing "polygon with holes" support for android #852

Closed
metalstrolch opened this issue Aug 29, 2019 · 11 comments
Closed

Missing "polygon with holes" support for android #852

metalstrolch opened this issue Aug 29, 2019 · 11 comments
Milestone

Comments

@metalstrolch
Copy link
Contributor

metalstrolch commented Aug 29, 2019

It is planned to include multipolygon support #824 into navit before 0.5.4 release, which is a good thing indeed.
However for full experience of the then enhanced maps, it would be good to add graphics support for drawing polygons with holes on Android, SDL and Windows CE targets as well.

I added Windows support (except CE) to #824 as it was no big issue to do even with only CI as build environment.

I added Windows CE support in #862

I added SDL support in #861

Despite willing to do so I cannot help much for android, as I don't have access to any Android device to test the result. But I am willing to help pointing out what needs to be done.

@metalstrolch metalstrolch added this to the 0.5.4 milestone Aug 29, 2019
@metalstrolch
Copy link
Contributor Author

Added Windows support except CE to #824.

@jkoan
Copy link
Member

jkoan commented Aug 29, 2019

Is there a way to add wince as well? i can do the test on wince

@metalstrolch
Copy link
Contributor Author

metalstrolch commented Aug 29, 2019

Not on the fly and not for me.
Windows CE seems to have a really limited and crippled GDI which doesn't support DrawPath used by me for win32. I fear that WindowsCE will be one of the platforms that doesn't have a native graphics library capable of drawing polygons with holes. So here we may be forced to manually triangulate.

But as not being a Windows dev, and the documentation about WindowsCE (C language specially) is really limited I may be wrong, but it seems I'm done here. I don't have any Device to test either, and the development cycles with only CI as build environment is rather slow.

Hopefully someone with Windows CE knowledge may help out here. Btw. I wonder that this old system is still in productive use.

-> I added WindowsCE support after seeing how it can be done in SDL.

@metalstrolch metalstrolch changed the title Missing "polygon with holes" support for android and windows Missing "polygon with holes" support for android, sdl and windows CE Sep 2, 2019
@metalstrolch
Copy link
Contributor Author

Add SDL with #861
Same attempt suitable for Windows CE.

@metalstrolch
Copy link
Contributor Author

Add Windows CE with #862

@metalstrolch metalstrolch changed the title Missing "polygon with holes" support for android, sdl and windows CE Missing "polygon with holes" support for android Sep 3, 2019
@pgrandin
Copy link
Contributor

Really nice work @metalstrolch

We have an experimental openSTF farm available. This could allow you to test android related features. Would you be interested?

@metalstrolch
Copy link
Contributor Author

Thanks for the offer @pgrandin,
but I think this may not make much sense. I'd need to refresh my knowledge on Java, learn about Android graphics API, and learn some JNI. Additionally I'd need to learn how to build and deploy to Android as I virtually never even used any Android device. And It would require me to set up a development environment as only CI is too slow a development cycle. It worked for Windows because it's just "C" and I were lucky i got it right with few iterations.

Last but not least it would require me to learn coding habits for Android, as #832 convinces me is something I better not make my fingers dirty. I don't like to be blamed for code I write for alien architectures barely knowing the system.

I was still hoping somebody with Android knowledge could at least try to set up the new graphics function. The learning curve seems to be too ineffective for doing this on my own.

  • Metalstrolch

metalstrolch added a commit that referenced this issue Sep 25, 2019
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
@lains
Copy link
Contributor

lains commented Sep 26, 2019

Hello @metalstrolch. I do have a build environment and several target machines for Android if testing is needed.
However, I have to say don't know much about Android graphics nor about navit's graphics subsystem... and I might bring long delays in the loop...

@pgrandin
Copy link
Contributor

@metalstrolch i understand your point about having to learn the java part. I'm in the same boat. I'll chime in #832 regarding CodeStyle but wanted to say this anyway : CodeStyle is a tool to help us improve our code. One way to do it is to fix old code style issues (there's sometimes really good fixes that can be uncovered) and another way is to prevent us from adding new issues.
Codestyle isn't a merge gate. Codestyle shouldn't be construed as a way to gauge someone's technical expertise.

Everybody is contributing with the goal to make Navit better. It's OK if you want to focus on one topic or one architecture. It's also OK if you submit a not perfect pull request to address an issue you've uncovered. Hopefully someone who knows more about that area can help and improve it.

Your contributions are welcome.

@metalstrolch
Copy link
Contributor Author

Ok, let ranting aside and do something, just to start another ranting.
I've started porting polygons with holes to Android in #889. It seems to semantically and syntactically to compile, but fails for style check once more. Since I cannot test this anyways, I leave dealing for to many or too less spaces before or after "if" in java code up to somebody knowing the tooling / style / habits.
How many style checks are there?
I don't wonder more and more only few people actually enhance Navit if every line you add / change fires a cascade of unrelated style check (spaces around ifs. OMG.) before ci actually presents you the result of the work you did. And looking at the compiler output it seems everybody is blinded by CodeFactory not complaining that the really important things (compiler warnings!) are not even cared for anymore. Sorry. But I abandon #889 unless we rethink those style check paranoia.

@metalstrolch
Copy link
Contributor Author

As #889 got merged we can now close this (even if #889 was still buggy) Follow on issue to fix the bug already existing.

viktorgino pushed a commit that referenced this issue Sep 22, 2020
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
jkoan pushed a commit to jkoan/navit that referenced this issue Jun 30, 2021
…vit-gps#879)

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 navit-gps#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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants