Registered Member
|
Hello!
Some fixes are needed for a long time but they are still absent or not really fixing issues. In code snippets below I will use "<...>" for omit some normal code, "///-" for deleted line, "///+" for added line and "///#" for fix comments, of course without quotes, as follows:
Ok, I'm starting now... 1) When drawing a polyline with a label at the end, out of bounds occurs in function ClipPainterPrivate::labelPosition (file ClipPainter.cpp).
2) When displaying two boxes handling crossing the IDL there may have duplicate objects from left and right box - this duplicates must be erased, otherwise they will be drawn twice. This effect can be seen on the semitransparent objects, such as user-opened files (kml for example) with alpha channel in fill polygon colors. Issue occurs in function GeoGraphicsScene::items (file GeoGraphicsScene.cpp).
3) Again, next issue occurs when displaying two boxes handling crossing the IDL - some placemarks may suddnely disappear from screen while the IDL is in view. However, though special case for IDL is provided, there are still disappearing placemarks, even with provided cities.txt / cityplacemarks.kml ! This is why another fix must be applied. Problem occurs in function PlacemarkLayout::visibleTiles (file PlacemarkLayout.cpp).
Please, someone, consider adding these fixes. I look forward to. Thanks! P.S. Sorry for my bad English... |
KDE Developer
|
Hi,
thanks for reporting and thanks for the fixes! I filed Bug #314539, Bug #314540 and Bug #314542 to make sure they are properly tracked. |
Registered Member
|
Earthwings!
Thank you for your help and patience! Can I post one more fix (it's about correct parsing shp-files including simple/stupid coloring for encountered polygons)? |
Administrator
|
If you will be submitting fixes often, you may wish to try submitting them via Reviewboard (https://git.reviewboard.kde.org), to ensure they are not lost.
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
KDE Developer
|
Sure. Either here, in Bugzilla or Reviewboard as bcooksley suggested - whatever works best for you. Thanks! |
Registered Member
|
Thanks for formalization and official fixes for Bug #314539 and Bug #314540 . But what about Bug #314542? Still no official fix, why?..
This version is obsolete. ShpParser updated. See this post, p.1. But lets back now. I want to public rewritten shp-plugin. Although this plugin is a simple shp-files parser, it's structure rather complicated. This is because of three things: 1. There is a try for coloring polygons based on it's objects distinctions based on dbf data. User can colorize each placemark after document was created but if shp-parser opens and reads dbf-file (using shapelib), doing similar work again seems superfluous. So shp-parser needs some settings (global defaults and per-file) to do simple colorizing based on dbf data. 2. There is no settings provided for "runner" (i.e. parser) plugins. But such settings can be nevertheless successfully used. 3. Some shape files are too large and cannot be simply parsed on 32-bit systems. GADM (full versions 1 and 2) - vivid example. I implemented quite stupid way to parse such files: if two points of a polygon is too close to each other, then one of the points is discarded. First time, we try to open file as usual and minimum distance between two points is null, But, if we ran into the lack of memory while parsing large file, we try again to open the file, but now the minimum distance is 1''. Again, if out of memory, next minimum is 1'. And so on. (On 32-bit Windows systems this trick is not working because of specific memory management, so you can try to use other memory allocators, such as nedmalloc patched dll - but there is no guarantee of results stability... But on Linux and others this must be ok...) This was (almost) successfully tested with some shapes from Natural Earth (10m - Admin0, Admin1, TimeZones and others) and from GADM (v1 all countries and v2 all-in-one). Now then, for correct shp-file parsing simply replace contents of the files ShpRunner.cpp and ShpRunner.h. ShpRunner.cpp:
ShpRunner.h:
If you will find (or already found) a better way/algorithm for simple (and universal) colorizing, please tell about and explain it. Thanks!
Last edited by artembogdanov on Fri May 17, 2013 6:56 pm, edited 3 times in total.
|
Registered Member
|
This version is obsolete. Try updated patch from this post, p.2
And after, I want to introduce some basic z-ordering when drawing in function GeometryLayer::render (file GeometryLayer.cpp).
Try to open these kml-files before and after the changes and you'll see the difference (in 3D-Globe mode of Earth). Zip-archive with example files can be downloaded from here: rghost.ru/45009252 (30 days)
Last edited by artembogdanov on Fri May 17, 2013 6:58 pm, edited 1 time in total.
|
Registered Member
|
bcooksley
And to wich repository (marble or marble-kde-org) should I submit review requests? |
KDE Developer
|
For marble, please. The marble-kde-org repository is the marble.kde.org website.
Regarding the z-order patch: I see two problems with the approach above, both performance related. First it does the ordering with a bubble sort approach, which has complexity O(n^2). Using qSort would be much faster. Second the ordering is done on each paint event. Instead it should be only done when items change, e.g. when they are added to the scene. |
Registered Member
|
Thank you! You are certainly right about performance issues. Also there is another issue - bad sorting of a three-dimensional shapes. This approach is only a draft, For this moment, I don't know how to solve this gracefully and correctly. But this is a temporary patch for those who need some z-ordering now and who do not care about this issues.
And what about Bug #314542? Is something wrong with it or with provided approach? Also, what about correct shapefiles parsing approach? Maybe I should do something? Please, tell me what to do, I'll try to. Thank you! |
Registered Member
|
Ok, while waiting for shp-parser to be committed, let me suggest a couple of another small fixes.
1) If you enable FileViewWidget, you may want to enable/disable or open/close user-opened documents (shapefiles, kml or others). Usually, everything's fine when you open or enable document (or separate objects in it). But when you try to disable document, you may see that not all document's objects gone from map. Furthermore, if you try to close that document, application will crash when rendering GeometryLayer. All this is because, when document deleted from TreeModel or erased at all from memory, not all of its objects deleted from GeoGraphicsScene. Root of the problem is in function GeoGraphicsScene::removeItem (file GeoGraphicsScene.cpp) - not all pointers to document's object are deleted from graphics scene.
2) Next fix is... obscure? Problem occurs in MarbleLegendBrowser::generateSectionsHtml (file MarbleLegendBrowser.cpp). Generating html from dgml, we add image properties tags. Among these properties is the path to the image file. Path generated by adding two strings - "file://" and canonical path. On Linux all seems to be ok, because Linux canonical paths begins with '/' symbol. The result is an url like "file:///opt/marble/data/bitmaps/flag.png", according to this article. But on Windows the result is invalid, like "file://c:/marble/data/bitmaps/flag.png". This result cannot be shown correctly in LegendWidget. We must add one more '/' to get normal "file:///c:/marble/data/bitmaps/flag.png" url. When we fix this, we fall into another problem. When image file is not used and canonical path is null, we finally get a stupid url like "file:///". On Windows, in release build such urls provokes an internal crash in Qt, resulting in application crash with error message from Microsoft Visual C++ Runtime Library: "Runtime error! <...> This application has requested the Runtime to terminate it in an unusual way. <...>". See Atlas theme (data/maps/earth/srtm/srtm.dgml - elevation explanation section) for such imageless elements. Consider to check is the following fix correct:
Thanks for attention and patience! |
KDE Developer
|
I filed Bug #318736 for the scene not being cleared properly.
For the legend problem I delegated the url generation to QUrl which is supposed to handle stuff like that, see Bug #318735. Can you test if that fixes it? I don't have a Windows system at hand at the moment. |
Registered Member
|
Earthwings
Thank you! Your fix works perfectly, and for empty path it generates string "file:" which does not crash Qt in release (and in debug of course) mode! Awesome! |
Registered Member
|
Another minor issue. If we switch off glowing on labels, in some circumstances labels does not fit to the calculated rectangles - last letters partially or completely not visible, especially when using italic font. Because of glowing always turned on by default (but comments in code say otherwise!), the problem goes unnoticed (?).
If we want to fix it, we must change something in function VisiblePlacemark::drawLabelPixmap (file VisiblePlacemark.cpp):
But if we look at PlacemarkLayer::render (file PlacemarkLayer.cpp), we can see that the same rectangle is calculated twice: when drawing label internally (VisiblePlacemark::drawLabelPixmap) and when drawing on screen (PlacemarkLayout::roomForLabel). Both rectangles must be the same, or we can fall into some performance issue because of QPainter::drawPixmap documented features (The pixmap is scaled to fit the rectangle, if both the pixmap and rectangle size disagree). Then we must do one more change in function PlacemarkLayout::roomForLabel (file PlacemarkLayout.cpp):
But both peaces of code are identical (except names labelName/labelText)! May be create new function in, say, VisiblePlacemark class? It would be much more logical and easier... Please consider to fix it correctly or use the draft patch above. P.S. I don't know why without "+ 1" last letter of non-glowing labels still can be shown only partially. But with "+ 1" it's all ok. I can upload screenshot(s) if in Linux this issue is not reproducible. To simply reproduce this issue in Windows go to the GeoDataLabelStyle.cpp file and replace all "m_glow( true )" strings with "m_glow( false )" ones. Then recompile and run. |
Registered Member
|
1. I want to share an updated version of shapefiles parser plugin. Fixed dramatic performance issue (marblewidget works with GeoDataMultiGeometry very slow, therefore GeoDataMultiGeometry now created only when it actually needed).
Colorizing was removed (a plugin which wants to colorize do this operation itself). Maybe, in future it will be re-added, based on the *.style files as in the ESRI ArcGIS. Also, code which works with settings, was totally removed. ShpRunner.cpp
ShpRunner.h
2. Also I want to share much more simple (without additional sorting and thus without additional performance penalties) Z-ordering. Nevertheless, a small additional performance penalty can occur in existing sorting (functions GeoGraphicsScene::addItem(GeoGraphicsItem*) and GeoGraphicsScenePrivate::addItems(const TileId&, QList<GeoGraphicsItem*>&, int). So, change some code in function GeometryLayerPrivate::createGraphicsItemFromGeometry (file GeometryLayer.cpp):
|
Registered users: bancha, Bing [Bot], Evergrowing, Google [Bot], lockheed, mesutakcan, Sogou [Bot]