spltter software design question
Hi, I am still working on the cleanup of the patch for splitter (splitter_problem_list.patch) I got the impression that the patched code is quite messed up now regarding the naming and use of interfaces and abstract classes. I'd like to change that so that a) - MapReader defines the interface to the IO routines that read OSM data, each format like pbf, o5m, or osm(xml) requires a special MapReader implementation. Current r202 defines an empty and more or less unused interface - MapProcessor defines the interface to the routines that should process the OSM data provided by the IO routines (nodes, ways, relations, etc). - OSMWriter defines the interface to the IO routines that write OSM data, each format like pbf, o5m, or osm(xml) requires a special OSMWriter implementation. Current r202 defines this as an abstract class. - class AbstractMapReader should contain common code in (at least two) readers - class AbstractMapProcessor should contain common code in (at least two) processors - class AbstractOSMWriter should contain common code in (at least two) writers b) The NodeCollector (used with parm --legacy-mode) seems to be obsolete to me, I want to remove it c) A few other helper classes are no longer in use (e.g. IntList, IntObjMap, SparseInt2ShortMap). I'd like to move them to a folder called obsolete What do you think about this? -- View this message in context: http://gis.19327.n5.nabble.com/spltter-software-design-question-tp5732135.ht... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Am 21.10.2012 12:30, schrieb GerdP:
Hi,
I am still working on the cleanup of the patch for splitter (splitter_problem_list.patch) I got the impression that the patched code is quite messed up now regarding the naming and use of interfaces and abstract classes.
I'd like to change that so that
a) - MapReader defines the interface to the IO routines that read OSM data, each format like pbf, o5m, or osm(xml) requires a special MapReader implementation. Current r202 defines an empty and more or less unused interface - MapProcessor defines the interface to the routines that should process the OSM data provided by the IO routines (nodes, ways, relations, etc). - OSMWriter defines the interface to the IO routines that write OSM data, each format like pbf, o5m, or osm(xml) requires a special OSMWriter implementation. Current r202 defines this as an abstract class.
- class AbstractMapReader should contain common code in (at least two) readers - class AbstractMapProcessor should contain common code in (at least two) processors - class AbstractOSMWriter should contain common code in (at least two) writers
b) The NodeCollector (used with parm --legacy-mode) seems to be obsolete to me, I want to remove it c) A few other helper classes are no longer in use (e.g. IntList, IntObjMap, SparseInt2ShortMap). I'd like to move them to a folder called obsolete
What do you think about this?
Hi Gerd, I don't have time to have a look into the changes. Only one hint about your design ideas: The OSMWriter is used by the mgkmap sea precompiler. So if you change that please change the mkgmap sea precompiler too. WanMil
Hi WanMil, WanMil wrote
Am 21.10.2012 12:30, schrieb GerdP:
What do you think about this?
I don't have time to have a look into the changes. Only one hint about your design ideas: The OSMWriter is used by the mgkmap sea precompiler. So if you change that please change the mkgmap sea precompiler too.
WanMil
Good that you tell me, I did not see that before. I'll have to find out how to build and sea precompiler, but it should not be a big problem. Ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/spltter-software-design-question-tp5732135p57... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi
- class AbstractMapReader should contain common code in (at least two) readers - class AbstractMapProcessor should contain common code in (at least two) processors - class AbstractOSMWriter should contain common code in (at least two) writers
Yes, that sounds fine.
b) The NodeCollector (used with parm --legacy-mode) seems to be obsolete to me, I want to remove it c) A few other helper classes are no longer in use (e.g. IntList, IntObjMap, SparseInt2ShortMap). I'd like to move them to a folder called obsolete
Let just remove everything that is not used. Over time there has been three different versions of the program that work in substantially different ways, so there are a few obsolete things. I'll set up a svn account for you too. ..Steve
Hi Steve,
- class AbstractMapReader should contain common code in (at least two) readers - class AbstractMapProcessor should contain common code in (at least two) processors - class AbstractOSMWriter should contain common code in (at least two) writers
Yes, that sounds fine.
OK, the pbf reader part is a bit difficult, because the interfaces are in the jar file, but the rest looks good to me.
b) The NodeCollector (used with parm --legacy-mode) seems to be obsolete to me, I want to remove it c) A few other helper classes are no longer in use (e.g. IntList, IntObjMap, SparseInt2ShortMap). I'd like to move them to a folder called obsolete
Let just remove everything that is not used.
OK
Over time there has been three different versions of the program that work in substantially different ways, so there are a few obsolete things.
I'll set up a svn account for you too.
OK, please let me know how I can use it :-) Ciao, Gerd
participants (4)
-
Gerd Petermann -
GerdP
-
Steve Ratcliffe -
WanMil