Multiple bugs in showing of KML files
After tests:
KML loaded to Google Earth:
https://dl.dropbox.com/u/4747589/Mapy...
KML loaded to Locus:
----------------------------------------------------------------------------------
[+] Coloured icons works fine
[+] Sizes of the icons are respected
[-] When icon is bigger then normal or when it has some colour - it is not "pumping up" when you move the cursor over it. Strangely they behave in the same way in Google Earth, so you may consider to make it better in Locus.
[-] Two areas overlayed on themselves are wrongly interpreted and only thhe holes between them are shown:
Google Earth:
Locus:
[-] Simple lines are stupidly interpreted as tracks:
Google Earth:
Locus:
I think the lines and areas should be totally bereft of the starting and ending points.
[-] The big yellow area is sometimes flickering annoyingly. And sometimes its badly painted and overlayed on the buttons!:
[-] original .kmz files has "doc.kml" inside them, but the filenames exported from Locus are strangely cut in half and they create some strange forms.
Hopefully this will help you improve KML integrity, because it is awesome! This is really starting to be GIS mobile app:) Congrats.
The same problem 
just few news:
[-] When icon is bigger then normal or when it has some colour - it is not "pumping up" when you move the cursor over it. Strangely they behave in the same way in Google Earth, so you may consider to make it better in Locus.
wrongly defined styles in your file, so that`s why Locus behave in same way as GE!
[-] Two areas overlayed on themselves are wrongly interpreted and only the holes between them are shown
I discovered problem with parsing areas, now it looks better. Only expect that tag is completely ignored so no small holes will be visible
[-] The big yellow area is sometimes flickering annoyingly. And sometimes its badly painted and overlayed on the buttons!
unfortunately problem with software rendered in Android
just few news:
[-] When icon is bigger then normal or when it has some colour - it is not "pumping up" when you move the cursor over it. Strangely they behave in the same way in Google Earth, so you may consider to make it better in Locus.
wrongly defined styles in your file, so that`s why Locus behave in same way as GE!
[-] Two areas overlayed on themselves are wrongly interpreted and only the holes between them are shown
I discovered problem with parsing areas, now it looks better. Only expect that tag is completely ignored so no small holes will be visible
[-] The big yellow area is sometimes flickering annoyingly. And sometimes its badly painted and overlayed on the buttons!
unfortunately problem with software rendered in Android
"wrongly defined styles in your file, so that`s why Locus behave in same way as GE! " - interesting, because I made a colour and size change within GE, no by external app.
"Only expect that tag is completely ignored so no small holes will be visible " - what do you mean by that exactly?
"unfortunately problem with software rendered in Android " - no possibilities at all? even in the future? so what can I do if i have the file with these areas? maybe some quick switch/checkbox to not load areas or to load areas without the fill ( just the borders of areas)
"wrongly defined styles in your file, so that`s why Locus behave in same way as GE! " - interesting, because I made a colour and size change within GE, no by external app.
"Only expect that tag is completely ignored so no small holes will be visible " - what do you mean by that exactly?
"unfortunately problem with software rendered in Android " - no possibilities at all? even in the future? so what can I do if i have the file with these areas? maybe some quick switch/checkbox to not load areas or to load areas without the fill ( just the borders of areas)
wrongly defined styles
----------------------------
you have for example defined style
<StyleMap id="file:M.Industry1.zip:bunker-2-2.png2">
<Pair>
<key>normal</key>
<styleUrl>#file:M.Industry1.zip:bunker-2-2.png1</styleUrl>
</Pair>
<Pair>
<key>highlight</key>
<styleUrl>#file:M.Industry1.zip:bunker-2-2.png</styleUrl>
</Pair>
</StyleMap>
where normal style bunker-2-2.png2 have scale 1.4, but highlight style bunker-2-2.png have scale also 1.4!! So that`s why hovered icon is same
invisible holes
-----------------
I wanted to write that inner tag is completely ignored, sorry. So inner holes will not be visible yet.
wrong rendering
--------------------
this is not happening so often in new A4.0, but problem is still there. It`s mainly because of software rendering and sorry, I see no possibility to fix it. Also disabling fill will not usually help. Problem is with drawing huge objects. As I saw, it doesn`t matter if they`re filled or not
wrongly defined styles
----------------------------
you have for example defined style
<StyleMap id="file:M.Industry1.zip:bunker-2-2.png2">
<Pair>
<key>normal</key>
<styleUrl>#file:M.Industry1.zip:bunker-2-2.png1</styleUrl>
</Pair>
<Pair>
<key>highlight</key>
<styleUrl>#file:M.Industry1.zip:bunker-2-2.png</styleUrl>
</Pair>
</StyleMap>
where normal style bunker-2-2.png2 have scale 1.4, but highlight style bunker-2-2.png have scale also 1.4!! So that`s why hovered icon is same
invisible holes
-----------------
I wanted to write that inner tag is completely ignored, sorry. So inner holes will not be visible yet.
wrong rendering
--------------------
this is not happening so often in new A4.0, but problem is still there. It`s mainly because of software rendering and sorry, I see no possibility to fix it. Also disabling fill will not usually help. Problem is with drawing huge objects. As I saw, it doesn`t matter if they`re filled or not
thanks for info.
in the topic about flickering: you are saying that even the not-filled areas will be flickering? I thought that they are just plain tracks/lines without, and tracks are not flickering. maybe in loading dialog for KML you will put some options like: "dont load areas", or "load areas as lines"?
"So inner holes will not be visible yet." - but you are planning to fix it in the future or totally abandon? should I remind you about that someday or will your JIRA remember it?
thanks for info.
in the topic about flickering: you are saying that even the not-filled areas will be flickering? I thought that they are just plain tracks/lines without, and tracks are not flickering. maybe in loading dialog for KML you will put some options like: "dont load areas", or "load areas as lines"?
"So inner holes will not be visible yet." - but you are planning to fix it in the future or totally abandon? should I remind you about that someday or will your JIRA remember it?
I generally think that all shapes that are huge, so they render a lot out of screen (android of course do not render it out of screen), cause such troubles. When you zoom out, so whole area is visible on screen, you don`t see this "flickering" right?
I had such problems with very long tracks on older devices. Same problem never happen on A4.X for me ...
So option - no. I hope I start work on "few years wanted" OpenGL support, so this will solve this problem
And inner areas - for this I also need one huge update. Complete re-writting of Tracks/Points and databases that hold them, because I`m currently not able to store such information. Ah, little bit - too much work to do :)
I generally think that all shapes that are huge, so they render a lot out of screen (android of course do not render it out of screen), cause such troubles. When you zoom out, so whole area is visible on screen, you don`t see this "flickering" right?
I had such problems with very long tracks on older devices. Same problem never happen on A4.X for me ...
So option - no. I hope I start work on "few years wanted" OpenGL support, so this will solve this problem
And inner areas - for this I also need one huge update. Complete re-writting of Tracks/Points and databases that hold them, because I`m currently not able to store such information. Ah, little bit - too much work to do :)
[-] Simple lines are stupidly interpreted as tracks: - this is still not fixed. When I load a area from kml file, and I will hover the cursor over the edge of this area - the line changes into the line with small triangles ( recorded tracks are behaving the same way)
There is no need to show what was the direction of drawing the line. They are just lines, without a direction.
It is also strange to show max speed and ,ax/min altitude and uphill/downhill/flat/total of the area (or the edge of this area). The chart shouldn`t be there also.
The only useful things are the points on the edge, and possibility to check their coordinates.
[-] Simple lines are stupidly interpreted as tracks: - this is still not fixed. When I load a area from kml file, and I will hover the cursor over the edge of this area - the line changes into the line with small triangles ( recorded tracks are behaving the same way)
There is no need to show what was the direction of drawing the line. They are just lines, without a direction.
It is also strange to show max speed and ,ax/min altitude and uphill/downhill/flat/total of the area (or the edge of this area). The chart shouldn`t be there also.
The only useful things are the points on the edge, and possibility to check their coordinates.
Replies have been locked on this page!