Projects/Marble/GraphicsViewGeoParser - Revision history

Bholst at 12:56, 31 March 2010

2010-03-31T12:56:27Z

Bholst at 12:55, 31 March 2010

2010-03-31T12:55:58Z

Bholst at 13:47, 9 September 2009

2009-09-09T13:47:46Z

Bholst at 13:44, 9 September 2009

2009-09-09T13:44:54Z

Tgridel at 21:18, 8 September 2009

2009-09-08T21:18:49Z

Tampakrap at 19:47, 8 September 2009

2009-09-08T19:47:32Z

Tgridel at 17:56, 8 September 2009

2009-09-08T17:56:35Z

Tgridel at 22:10, 22 July 2009

2009-07-22T22:10:44Z

Mansona: Created page with '== GeoParser and the GeoGraphicsView == The current GeoData XML Parser ( aka. GeoParser ) has been implemented to specifically deal with our current GeoData data structure. If y...'

2009-07-09T14:01:56Z

Created page with '== GeoParser and the GeoGraphicsView == The current GeoData XML Parser ( aka. GeoParser ) has been implemented to specifically deal with our current GeoData data structure. If y...'

New page

== GeoParser and the GeoGraphicsView ==
The current GeoData XML Parser ( aka. GeoParser ) has been implemented to specifically deal with our current GeoData data structure. If you want to see a more complete documentation of the GeoData library you can see the [[Projects/Marble/LibGeoData|GeoData Library documentation]]. I will only describe the particular problem to the GeoGraphicsView implementation here.


=== Parsing GeoData ===
The GeoParser is an implementation of the QXMLStreamReader class in Qt, more information can be found [http://doc.qtsoftware.com/4.5/qtxml.html here]. There are other things built into this implementation that simplify the creation of a parser for new XML format document, namely:
* The Concept of a TagHandler class that deals with only one tag
* A Stack Item class that implements the Structural parts of the XML document
* The collection class where the results of the XML parsing will be placed
* A element dictionary that prevents the need for string comparison everywere

To implement a new XML parser you need to
#compile an element dictionary of all of the available tags in the namespace
#implement a tag handler for each of these elements
#register that tag handler with the GeoParser

==== Implementing a tag handler ====
Each tag handler is called when the relevant XML tag is reached by the GeoParser ( which knows what tags to call by its registered tag list ). Each tag can access the stack data structure of the GeoParser as well as the Collection Data Structure of the GeoParser. This allows the tag handler to access items from the stack and allows root elements of the XML to add themselves to the collection data structure.


=== Down Casting ===
The unfortunate thing about the current implementation of the GeoParser is that when any item is added to the Collection Data Structure it is effectively downcast to the collection's type and removes any ability for 3rd party developers to add parsing capability to marble with functionality other than that which marble provides. This is not in line with the design of the QGraphicsItem implementation and something that is a current development effort to fix. What needs to happen is that an extra data model needs to be added to the GeoParser that is more in line with the idea of passing pointers around and that way we can conserve the typing information at run time.

← Older revision		Revision as of 12:56, 31 March 2010
Line 59:		Line 59:

	=== Rethink the GeoData classes ===		=== Rethink the GeoData classes ===
−	It's unclear, if it is reasonable to save ALL GeoData* classes as a value, with "implicit sharing" making it fast. Multi-level data stored as a value is a bit complicated. This will be discussed [[Projects/Marble/GeoData/PointerVsImplicitShare ~~here~~]]	+	It's unclear, if it is reasonable to save ALL GeoData* classes as a value, with "implicit sharing" making it fast. Multi-level data stored as a value is a bit complicated. This will be discussed in [[Projects/Marble/GeoData/PointerVsImplicitShare]]

@@ Line 8: / Line 8: @@
 The Link between GeoData and GeoGraphicsItems has to permit:
 * To display corresponding items, and get the data updates.
-* To possibly edit data through interaction (i.e. clicking on the map, dragging an item...)
+* To edit data through interaction (i.e. clicking on the map, dragging an item, changing the text of a placemark, adding placemarks)
 == A bit of history and issues ==
@@ Line 18: / Line 18: @@
 A "Model" in the Model-view framework in Qt is an interface to facilitate access to lists of data from widgets which need not know what data is inside. The interface may sound nice, but the abstraction is a bit too much when the interaction between data and its representation increases. These "Model" are also not data stores in order to avoid the previous issue.
 == Possible Solutions and discussion ==
 === Time of creation of GeoGraphicsItems ===
@@ Line 28: / Line 31: @@
 This leads to the problem when to create the GeoGraphicsItems for displaying on the scene:
 * Creating the items as they were read.
-** This will probably be really slow as GeoGraphicsItems shouldn't be created in the thread which parses the file.
+** This will probably be really slow as GeoGraphicsItems shouldn't be created in the thread which parses the file (why not?)
-** This will use lots of memory as everything has to be ready for painting.
+** This will use (lots of) memory as everything has to be ready for painting.
-* Using a proxy concept: In another Thread runs a check for the GeoDataFeatures and GeoDataGeometries which entered the scene (because of moving around). This will probably go through a list of say 20000 entries, but, as it runs in a thread it won't stop the user interface from repainting. As the user interface repaints (in main thread), the GeoGraphicsItems for the new GeoData...-objects are created (we know which are needed because of our Proxy-Thread). Our MarbleGraphicsScene allows to add items temporary, removing them when they are out of the viewport for some time. Our MarbleGraphicsScene would hold about 200 entries, which can be access via a list or a [http://en.wikipedia.org/wiki/Binary_space_partitioning BSP-tree] (depending on which turns out to be more reasonable).
+* Using a proxy concept: In another Thread runs a check for the GeoDataFeatures and GeoDataGeometries which entered the scene (because of moving around). This will probably go through a list of say 20000 entries, but, as it runs in a thread it won't stop the user interface from repainting. As the user interface repaints (in main thread), the GeoGraphicsItems for the new GeoData...-objects are created (we know which are needed because of our Proxy-Thread). Our GeoGraphicsScene allows to add items temporary, removing them when they are out of the viewport for some time. Our GeoGraphicsScene would hold about 200 entries, which can be access via a list or a [http://en.wikipedia.org/wiki/Binary_space_partitioning BSP-tree] (depending on which turns out to be more reasonable).
 === Display the data ===
@@ Line 45: / Line 49: @@
 * implement light event handling methods (like java event listener classes)
 * use qt's model-view framework of itemviews-ng
@@ Line 54: / Line 57: @@
 === Edit the data ===
 We should think carefully about storing data to provide the second goal, so that editing is done in the GeoData and then updates happen in GeoGraphicsItems as a result.

@@ Line 29: / Line 29: @@
 * Creating the items as they were read.
 ** This will probably be really slow as GeoGraphicsItems shouldn't be created in the thread which parses the file.
 * Using a proxy concept: In another Thread runs a check for the GeoDataFeatures and GeoDataGeometries which entered the scene (because of moving around). This will probably go through a list of say 20000 entries, but, as it runs in a thread it won't stop the user interface from repainting. As the user interface repaints (in main thread), the GeoGraphicsItems for the new GeoData...-objects are created (we know which are needed because of our Proxy-Thread). Our MarbleGraphicsScene allows to add items temporary, removing them when they are out of the viewport for some time. Our MarbleGraphicsScene would hold about 200 entries, which can be access via a list or a [http://en.wikipedia.org/wiki/Binary_space_partitioning BSP-tree] (depending on which turns out to be more reasonable).

@@ Line 23: / Line 23: @@
 == Possible Solutions and discussion ==
 === Display the data ===
 We should follow an [http://en.wikipedia.org/wiki/Observer_pattern Observer Pattern] logic for the first goal whereas GeoGraphicsItems would observe the GeoData.

@@ Line 27: / Line 27: @@
 Multiple options are available for an observer pattern implementation:
-* use signal/slots (after all, this is one of Qt's best success)
+* use signal/slots
 * implement light event handling methods (like java event listener classes)
-* use qt's model-view framework of itemviews-ng (more info needed to see if it fits the observer solution)
 === Edit the data ===
 We should think carefully about storing data to provide the second goal, so that editing is done in the GeoData and then updates happen in GeoGraphicsItems as a result.

@@ Line 1: / Line 1: @@
-== GeoParser and the GeoGraphicsView ==
+== The Problem ==
-The current GeoData XML Parser ( aka. GeoParser ) has been implemented to specifically deal with our current GeoData data structure. If you want to see a more complete documentation of the GeoData library you can see the [[Projects/Marble/GeoData|GeoData documentation]]. I will only describe the particular problem to the GeoGraphicsView implementation here.
+Data is read from files with the [[Projects/Marble/GeoData/GeoDataParsing|GeoDataParser framework]] in order to be displayed.
-=== Casting ===
+The [[Projects/Marble/GeoData|GeoData framework]] is used to manipulate {{class|GeoDataObject|kdeedu|4.x}} classes. GeoData should be accessed in a sensible way because of its "shared data" logic.
-The unfortunate thing about the current implementation of the GeoParser is that when any item is added to the Collection Data Structure it is effectively cast as an {{class|GeoNode|kdeedu|4.2}} and removes any ability for 3rd party developers to add parsing capability to marble with functionality other than that which marble provides. This is an issue that needs more investigation to provide more flexibility.
-=== Link between GeoData and GeoGraphicsItems ===
+Items to be displayed are {{class|GeoGraphicsItems|kdeedu|4.x}}, following the [[Projects/Marble/GeoGraphicsViewOverview|GeoGraphicsView]] framework.
-Previously, GeoData has been accessed through pointers from the rendering objects. this poses problems as GeoData uses data sharing and updates in GeoData are thus not seen in Items.
-It could be possible to do multiple inheritance where GeoGraphicsItems would also be GeoNodes, but that raises issues regarding modularity, because both the model and its representation would be in the same object.
+The Link between GeoData and GeoGraphicsItems has to permit:
-The better solution would follow an [http://en.wikipedia.org/wiki/Observer_pattern observer pattern] logic whereas GeoGraphicsItems would react to GeoData. Multiple options are available:
+== A bit of history and issues ==
-* use signal/slots
+=== GeoData manipulation ===
-* implement light event handling methods
+Previously, GeoData has been accessed through shallow copy from the rendering objects. this posed problems as GeoData uses data sharing internally and updates in GeoData were thus not seen in Items.
 * use qt's model-view framework of model-view-ng

@@ Line 1: / Line 1: @@
 == GeoParser and the GeoGraphicsView ==
-The current GeoData XML Parser ( aka. GeoParser ) has been implemented to specifically deal with our current GeoData data structure. If you want to see a more complete documentation of the GeoData library you can see the [[Projects/Marble/LibGeoData|GeoData Library documentation]]. I will only describe the particular problem to the GeoGraphicsView implementation here.
+The current GeoData XML Parser ( aka. GeoParser ) has been implemented to specifically deal with our current GeoData data structure. If you want to see a more complete documentation of the GeoData library you can see the [[Projects/Marble/GeoData|GeoData documentation]]. I will only describe the particular problem to the GeoGraphicsView implementation here.
-<!-- move this section to a dedicated "How the XML parser works" section -->
+=== Casting ===
-=== Parsing GeoData ===
+The unfortunate thing about the current implementation of the GeoParser is that when any item is added to the Collection Data Structure it is effectively cast as an {{class|GeoNode|kdeedu|4.2}} and removes any ability for 3rd party developers to add parsing capability to marble with functionality other than that which marble provides. This is an issue that needs more investigation to provide more flexibility.
-The GeoParser is an implementation of the QXMLStreamReader class in Qt, more information can be found [http://doc.qtsoftware.com/4.5/qtxml.html here]. There are other things built into this implementation that simplify the creation of a parser for new XML format document, namely:
-* The Concept of a TagHandler class that deals with only one tag
-* A Stack Item class that implements the Structural parts of the XML document
-* The collection class where the results of the XML parsing will be placed
-* A element dictionary that prevents the need for string comparison everywere
-To implement a new XML parser you need to
+=== Link between GeoData and GeoGraphicsItems ===
-#compile an element dictionary of all of the available tags in the namespace
+Previously, GeoData has been accessed through pointers from the rendering objects. this poses problems as GeoData uses data sharing and updates in GeoData are thus not seen in Items.
-#implement a tag handler for each of these elements
-#register that tag handler with the GeoParser
-==== Implementing a tag handler ====
+It could be possible to do multiple inheritance where GeoGraphicsItems would also be GeoNodes, but that raises issues regarding modularity, because both the model and its representation would be in the same object.
-Each tag handler is called when the relevant XML tag is reached by the GeoParser ( which knows what tags to call by its registered tag list ). Each tag can access the stack data structure of the GeoParser as well as the Collection Data Structure of the GeoParser. This allows the tag handler to access items from the stack and allows root elements of the XML to add themselves to the collection data structure.
-<!-- more information needed when moved to its own page -->
-=== Down Casting ===
+The better solution would follow an [http://en.wikipedia.org/wiki/Observer_pattern observer pattern] logic whereas GeoGraphicsItems would react to GeoData. Multiple options are available:
-The unfortunate thing about the current implementation of the GeoParser is that when any item is added to the Collection Data Structure it is effectively downcast to the collection's type and removes any ability for 3rd party developers to add parsing capability to marble with functionality other than that which marble provides. This is not in line with the design of the QGraphicsItem implementation and something that is a current development effort to fix. What needs to happen is that an extra data model needs to be added to the GeoParser that is more in line with the idea of passing pointers around and that way we can conserve the typing information at run time.
+* use signal/slots