Re: [JPP-Devel] Error with Map coloring plugin
Hey Jukka, It might be possible to detect that less than 5 polygons are touching at a point and treat that particular area as through the features were adjacent to get the behavior in the 0.4 version of the plugin. However, it would complicate the code quite a bit and slow it down. Regarding packaging the plugin into a libfolder in lib\ext\ojmapcoloring-0.5, I used to do that with the DB Query plugin, and prefer it also, but recent versions of OJ don't load plugins unless they are in the lib\ext directory. I'm using Linux OpenJUMP-1.6.1-r3501-PLUS to test. Maybe the Windows versions behave differently? -lreeder On Sun, Sep 28, 2014 at 2:41 AM, Rahkonen Jukka (Tike) jukka.rahko...@mmmtike.fi wrote: Hi Larry, Version 0.5 colors now all the Finnish municipalities and all the multi-slice pizzas which I digitized fine. However, I think that when there are at maximum 5 areas touching on one point the version 0.4 does better coloring. The new version may give the same color for areas which touch on one point even it would not be necessary. My municipality map seems to be a good test dataset because it has a) multipolygons where the parts are touching on one point - parts should be painted with the same color and b) separate simple polygons touching on one point - would be better to paint with different colors if possible. If I had to select between 0.4 and 0.5 I think I would select 0.4 because of the better coloring result in normal cases. I prefer to keep the lib\ext folder a bit more clean by copying only ojmapcoloring.jar there and putting the rest of the package into folder lib\ext\ojmapcoloring-0.5. Perhaps it is still not worth changing the packaging or installation instructions. -Jukka Rahkonen- Larry Reeder wrote: Well, no matter how many times you slice it, a pizza is always (mostly) planar :-). The problem with map coloring occurs when you can't draw a line on a plane from a fixed point on all features to a fixed point on their adjacent features without the lines crossing. You have to lift the lines off the plane to connect adjacent features, so the adjacency graph becomes non-planar. I've got a fix for it now, one that doesn't count features touching on a point as adjacent. Give it a try - https://sourceforge.net/projects/ojmapcoloring/files/0.5/ -lreeder On Mon, Sep 22, 2014 at 4:09 AM, Rahkonen Jukka (Tike) jukka.rahko...@mmmtike.fi wrote: Hi Larry, I should have actually guessed what happened. There used to be 8 municipalies sharing a common landmark but because of some fusions there are only 6 left now. I tried to find a document that says that pizza is no more planar when it is sliced into 6 pieces. However, I found some documents which define the four or five color theorem so that polygons are considered to be adjacent if they share an edge, not only a point. This is one of those http://www.mathpages.com/home/kmath266/kmath266.htm. -Jukka- Larry Reeder wrote: Hey Jukka, Just got a chance to look at this. The region that is not coloring is interesting. It's like a pizza sliced into six pieces, each touching at the point. You can't color this portion of the map with only five colors without two adjacent (maybe just adjacent at one point in the enter) regions having the same color. In graph-theory terms, the graph is non-planar and can't be colored correctly with the five-color theorem. The map coloring plugin detects this and refuses to color this portion of the map. From a practical standpoint, you probably don't care that regions touching at a single point have the same color, as long as they don't share a color along a long edge. I'll look at updating the plugin to detect this and continue coloring. -lreeder On Mon, Sep 15, 2014 at 7:15 AM, Rahkonen Jukka (Tike) jukka.rahko...@mmmtike.fi wrote: Hi, I found a shapefile from which some polygons are not colored with the Map coloring plugin v. 0.4. Shapefile does not have topology errors but some multipolygons have quite a many parts because of archipelago. However, exploding multipolygons into polygons does not change the behaviour. The problematic shapefile can be found from http://latuviitta.org/downloads/ojmapcolor_error.zip Error appears always in the same place in South-West. For example features with OGR_FID=180 or 234 stays without color. -Jukka Rahkonen- -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Error with Map coloring plugin
On 05.10.2014 16:09, Larry Reeder wrote: Regarding packaging the plugin into a libfolder in lib\ext\ojmapcoloring-0.5, I used to do that with the DB Query plugin, and prefer it also, but recent versions of OJ don't load plugins unless they are in the lib\ext directory. I'm using Linux OpenJUMP-1.6.1-r3501-PLUS to test. Maybe the Windows versions behave differently? that's kind of my department as i did the latest changes ;) .. let me shed some light on it. the vision - is to have extensions placing one jar (containing the extension class) into lib/ext and their libs/files into a subfolder e.g. lib\ext\ojmapcoloring-0.5.jar lib\ext\ojmapcoloring-0.5\dependency.jar lib\ext\ojmapcoloring-0.5\readme.txt ... eventually i dream of modifying the plugin loading in a way that concurrent library versions in extensions will be possible by using one classloader per plugin. therefor the foldernames of course will have to be standardized e.g. like above. the status quo - to speedup the loading process not all jars recursively are searched for extension classes, but only those in lib/ext. but to prepare for the vision and also to clean up lib/ext in general it is already possible to package extensions like described above. please try ;).. ede -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Macro recorder for OpenJUMP (work in progress)
Hi Jumpers, I've started to add a big feature for OJ : capability to record macros. I did not find a way to implement it without the need to revisit each plugin, but I tried to adopt a design - which does not break existing plugins - where adaptation to make a plugin recordable in a macro is minimal The general idea is : - make plugins persistable along with its parameters - make plugins runnable from a map of parameters (instead of an interactive dialog box) To achieve that in a simple way, plugins must be able to store/access their parameters through a simple MapString,Object Usually, to make a plugin recordable : - you must put parameters gathered from a MultiInputDialog into a map - refactor the code so that it accepts the map values as parameters instead of named plugin attributes (see changes in BufferPlugIn) I have tested the concept with several different tools : - DisposeSelectedLayerPlugIn - BufferPlugIn - ViewSchemaPlugIn - DataSourceFileLayerLoader Some are easy to adapt (ex. DisposeSelectedLayerPlugIn), other are difficult (ex. ViewSchemaPlugIn) Any comment about the design is welcome Any help to make all our plugins recordable is welcome Michaël -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Error with Map coloring plugin
Hi , I was rather thinking that users could select the v. 0.4 path at their own risk for example by checking a box “Disjoint colors” with a tooltip hint “Tries to prevent same colors from touching at any point”. But that is not especially important feature and I do like simple and fast solutions a lot. -Jukka Rahkonen- Larry Reeder wrote: Hey Jukka, It might be possible to detect that less than 5 polygons are touching at a point and treat that particular area as through the features were adjacent to get the behavior in the 0.4 version of the plugin. However, it would complicate the code quite a bit and slow it down. Regarding packaging the plugin into a libfolder in lib\ext\ojmapcoloring-0.5, I used to do that with the DB Query plugin, and prefer it also, but recent versions of OJ don't load plugins unless they are in the lib\ext directory. I'm using Linux OpenJUMP-1.6.1-r3501-PLUS to test. Maybe the Windows versions behave differently? -lreeder On Sun, Sep 28, 2014 at 2:41 AM, Rahkonen Jukka (Tike) jukka.rahko...@mmmtike.fimailto:jukka.rahko...@mmmtike.fi wrote: Hi Larry, Version 0.5 colors now all the Finnish municipalities and all the multi-slice pizzas which I digitized fine. However, I think that when there are at maximum 5 areas touching on one point the version 0.4 does better coloring. The new version may give the same color for areas which touch on one point even it would not be necessary. My municipality map seems to be a good test dataset because it has a) multipolygons where the parts are touching on one point - parts should be painted with the same color and b) separate simple polygons touching on one point - would be better to paint with different colors if possible. If I had to select between 0.4 and 0.5 I think I would select 0.4 because of the better coloring result in normal cases. I prefer to keep the lib\ext folder a bit more clean by copying only ojmapcoloring.jar there and putting the rest of the package into folder lib\ext\ojmapcoloring-0.5. Perhaps it is still not worth changing the packaging or installation instructions. -Jukka Rahkonen- Larry Reeder wrote: Well, no matter how many times you slice it, a pizza is always (mostly) planar :-). The problem with map coloring occurs when you can't draw a line on a plane from a fixed point on all features to a fixed point on their adjacent features without the lines crossing. You have to lift the lines off the plane to connect adjacent features, so the adjacency graph becomes non-planar. I've got a fix for it now, one that doesn't count features touching on a point as adjacent. Give it a try - https://sourceforge.net/projects/ojmapcoloring/files/0.5/ -lreeder On Mon, Sep 22, 2014 at 4:09 AM, Rahkonen Jukka (Tike) jukka.rahko...@mmmtike.fimailto:jukka.rahko...@mmmtike.fi wrote: Hi Larry, I should have actually guessed what happened. There used to be 8 municipalies sharing a common landmark but because of some fusions there are only 6 left now. I tried to find a document that says that pizza is no more planar when it is sliced into 6 pieces. However, I found some documents which define the four or five color theorem so that polygons are considered to be adjacent if they share an edge, not only a point. This is one of those http://www.mathpages.com/home/kmath266/kmath266.htm. -Jukka- Larry Reeder wrote: Hey Jukka, Just got a chance to look at this. The region that is not coloring is interesting. [cid:image001.jpg@01CFE0D1.B3C87800] It's like a pizza sliced into six pieces, each touching at the point. You can't color this portion of the map with only five colors without two adjacent (maybe just adjacent at one point in the enter) regions having the same color. In graph-theory terms, the graph is non-planar and can't be colored correctly with the five-color theorem. The map coloring plugin detects this and refuses to color this portion of the map. From a practical standpoint, you probably don't care that regions touching at a single point have the same color, as long as they don't share a color along a long edge. I'll look at updating the plugin to detect this and continue coloring. -lreeder On Mon, Sep 15, 2014 at 7:15 AM, Rahkonen Jukka (Tike) jukka.rahko...@mmmtike.fimailto:jukka.rahko...@mmmtike.fi wrote: Hi, I found a shapefile from which some polygons are not colored with the Map coloring plugin v. 0.4. Shapefile does not have topology errors but some multipolygons have quite a many parts because of archipelago. However, exploding multipolygons into polygons does not change the behaviour. The problematic shapefile can be found from http://latuviitta.org/downloads/ojmapcolor_error.zip Error appears always in the same place in South-West. For example features with OGR_FID=180 or 234 stays without color. -Jukka Rahkonen- -- Want excitement?
Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)
On 05.10.2014 17:57, Michael Michaud wrote: Hi Jumpers, I've started to add a big feature for OJ : capability to record macros. that's really a nice feature! i like it.. without looking at the implementation details (you explained it pretty good), here some questions remarks. first and most important question: are all non-interactive (dialogless) recordable now out of the box? I did not find a way to implement it without the need to revisit each plugin, but I tried to adopt a design - which does not break existing plugins - where adaptation to make a plugin recordable in a macro is minimal what happens when during macro recording and a non-recordable plugin is executed? The general idea is : - make plugins persistable along with its parameters - make plugins runnable from a map of parameters (instead of an interactive dialog box) To achieve that in a simple way, plugins must be able to store/access their parameters through a simple MapString,Object Usually, to make a plugin recordable : - you must put parameters gathered from a MultiInputDialog into a map - refactor the code so that it accepts the map values as parameters instead of named plugin attributes (see changes in BufferPlugIn) I have tested the concept with several different tools : - DisposeSelectedLayerPlugIn - BufferPlugIn - ViewSchemaPlugIn - DataSourceFileLayerLoader Some are easy to adapt (ex. DisposeSelectedLayerPlugIn), other are difficult (ex. ViewSchemaPlugIn) i am pretty sure you had a specific use case in mind. could you post a simple step-by-step list of it that would illustrate a workflow that profits from automating? Any comment about the design is welcome Any help to make all our plugins recordable is welcome that's my main issue with your approach. A. who is going to make at least most of our plugins recordable? shouldn't there be a mode where interactive plugins are allowed and come up with their respective dialog during automation? B. our non-interactive plugins (e.g. Copy,Cut,Paste..) should be enabled by default, if they are not already by your current implementation. C. users will assume that they can record _any: workflow when they use this feature, not just some enabled plugins. if we'd go down this road we should disable (via the Enabled interface) plugins that are not automatable during recording. one implementation for C. could be a Plugin wrapper, that implements the Plugin interface and is instantiated given the original plugin. as _all_ our plugins are now installed via one routine we could easily wrap each plugin in this RecordableCheckedPlugin one during the startup. RecordableCheckedPlugin could then implement - an additional EnabledCheck which is enabled during recording and de/activates the plugin according to it's implemented interface. . just some quick thoughts ;).. ede -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] OJ Wiki
Hi Ede, Edit seems to be possible now, thanks. -Jukka- -Alkuperäinen viesti- Lähettäjä: edgar.sol...@web.de [mailto:edgar.sol...@web.de] Lähetetty: 2. lokakuuta 2014 19:29 Vastaanottaja: OpenJump develop and use Aihe: Re: [JPP-Devel] OJ Wiki please retry.. ede On 01.10.2014 14:41, Rahkonen Jukka (Tike) wrote: Hi Ede, I would like to make some updates to wiki. I can log in with my account but not edit. -Jukka- edgar soldin wrote: hmm.. it should be write protected as i didn't find the time or energy to setup user mgmt so far ;(.. ede On 13.09.2014 19:39, Michael Michaud wrote: I got it, Just received my temporary password, Michaël Hi Ede, I've been unable to get write access to the new wiki. Can you give me a hint ? Should I create a new account (I could not) Thanks, Michaël no. you are free to familiarize yourself with these platforms and to do so. afaics the swing ui and feature rich desktop approach of OJ will probably make any port as such unfeasible. ..ede On 15.07.2014 14:45, sukhjit sehra wrote: Any body working on conceptualization of Open Jump on to Mobile devices such as android/ios thanks On Sun, Jul 13, 2014 at 8:49 PM, edgar.sol...@web.de mailto:edgar.sol...@web.de wrote: the wiki is online again. you can follow the links on http://openjump.org . for now there is no registration or editing. that will come in a next step, as users will have to reregister and i have the permissions not properly set up so far. the webspace is located in germany and should be sufficiently responsive and fast from all over the world. here are the reasons why i ended up there: why not sf.net http://sf.net? because my other much smaller wiki is disastrously slow. the pages need several seconds most of the time, sometimes even longer. especially when you try to edit something ending up with timeouts is a deal breaker. other 'free' mediawiki hosters? i had a look around. but it already started with me having the old wiki in form of an sql dump and the files in an archive. this is simply not the format these services allow to import. they prefer an xml export, that unfortunately omits all image files. the same issue would have hit us when moving from one hoster to another. there are scripts avail to export mediawiki via API calls and web access, but that was something i definitely didn't wanted to invest effort in. so far, so jumpy.. ede -- ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net mailto:Jump-pilot- de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Er. Sukhjit Singh Sehra Assistant Professor Dept of Computer Science Engg. Guru Nanak Dev Engineering College, Ludhiana, Punjab Mobile No:- 09855959200 *In your free time kindly visit Sikh-relics.com - A Gallery of Blessed Relics of Sikh Guru Sahib - -- --- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- -- -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel --- -- - Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/os tg .clktrk ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel --
Re: [JPP-Devel] Macro recorder for OpenJUMP (work in progress)
Hi Ede, Thanks for the feed-back On 05.10.2014 17:57, Michael Michaud wrote: Hi Jumpers, I've started to add a big feature for OJ : capability to record macros. that's really a nice feature! i like it.. without looking at the implementation details (you explained it pretty good), here some questions remarks. first and most important question: are all non-interactive (dialogless) recordable now out of the box? Absolutely not. When there is no dialog the adaptation is minimal (ex. DisposeSelectedLayerPlugIn). Don't know if it can be reduced to nothing by adding some code in AbsractPlugIn but the problem is that plugins with or without dialog have the same interface. I did not find a way to implement it without the need to revisit each plugin, but I tried to adopt a design - which does not break existing plugins - where adaptation to make a plugin recordable in a macro is minimal what happens when during macro recording and a non-recordable plugin is executed? Just ignored. Until I add a piece of code at the end of plugin execution, the action is executed as before, but not added to the macro. The general idea is : - make plugins persistable along with its parameters - make plugins runnable from a map of parameters (instead of an interactive dialog box) To achieve that in a simple way, plugins must be able to store/access their parameters through a simple MapString,Object Usually, to make a plugin recordable : - you must put parameters gathered from a MultiInputDialog into a map - refactor the code so that it accepts the map values as parameters instead of named plugin attributes (see changes in BufferPlugIn) I have tested the concept with several different tools : - DisposeSelectedLayerPlugIn - BufferPlugIn - ViewSchemaPlugIn - DataSourceFileLayerLoader Some are easy to adapt (ex. DisposeSelectedLayerPlugIn), other are difficult (ex. ViewSchemaPlugIn) i am pretty sure you had a specific use case in mind. could you post a simple step-by-step list of it that would illustrate a workflow that profits from automating? Not precisely. I know that OpenJUMP is efficient for prototyping or to do one shot production, but that it has limitations to do repetitive tasks in a production environment. : Exemple (fictive) - get a dataset from a partner - tansform the schema - join the data with our own data to keep data of interest only - save or upload to a database Any comment about the design is welcome Any help to make all our plugins recordable is welcome that's my main issue with your approach. A. who is going to make at least most of our plugins recordable? shouldn't there be a mode where interactive plugins are allowed and come up with their respective dialog during automation? There is a lot of work to make all plugins recordable but it can be done progressively. I would have liked to find a way to make plugins recordable all at one time but there is a great variety of implementations, and it seems difficult to me. For example, it took me several hours to find where to implement my piece of code to make open this shapefile recordable in a macro (not in a plugin). Interesting question about mixing macro and dialog. From my point of view, macro should not open dialog, but I can imagine particular cases where a dialog is needed. It would add much complexity though. B. our non-interactive plugins (e.g. Copy,Cut,Paste..) should be enabled by default, if they are not already by your current implementation. I'll give more thought about it. Not sure that you can implement something working for these plugins without interfering with other plugins as execute() may either - do an action or - open a dialog I think if we implement a general method for non-interactive plugin (ex in AbstractPlugIn) the side effect will be that dialog-based plugins will also be recorded and executed by opening their dialog within a macro. This behaviour maybe acceptable, and maybe easy to fix through a new abstract class or interface to differenciate different kinds of plugins. C. users will assume that they can record _any: workflow when they use this feature, not just some enabled plugins. if we'd go down this road we should disable (via the Enabled interface) plugins that are not automatable during recording. Good point one implementation for C. could be a Plugin wrapper, that implements the Plugin interface and is instantiated given the original plugin. as _all_ our plugins are now installed via one routine we could easily wrap each plugin in this RecordableCheckedPlugin one during the startup. RecordableCheckedPlugin could then implement - an additional EnabledCheck which is enabled during recording and de/activates the plugin according to it's implemented interface. Seems a good idea. Plugins should explicitely inherit their parent's EnabledCheck in this case. It would also need to check-up/update all plugins or did I misses the point ? just
