Re: [JPP-Devel] wishlist
Hi, One further question: How are you going to get the ID of the newly inserted feature back to OpenJUMP side? -Jukka- -Original Message- From: Kevin Neufeld [mailto:kneuf...@refractions.net] Sent: Mon 6.9.2010 9:35 To: OpenJump develop and use Subject: Re: [JPP-Devel] wishlist Hi Jukka, Yes, inserts are more tricky than other modification types. However, IMHO, a properly modeled database will include sequence generators, rules, or triggers on database tables enforcing the primary key attribute. My first iteration through this will be to simply target the most common use case, that is, during an insert operation, specify all attributes except the primary key (whether single or multi-column key) and let the database populate the field(s) automatically. If the attempt fails, then there are options: 1) Do nothing, rollback the transaction and notify the user they are missing sequences on their primary key columns 2) Again, warn the user their database modeling needs work and try the commonly used max(ID) approach to guess the primary key entry (maybe in a confirmation dialog). However, this is definitely not recommended. What if the column is alphanumeric? What's the max(ID) then? What if it's, as you point out, a multiple-key column? Obviously we can't guess that. What if it was intentional that a sequence was not provided? Maybe the table is considered read-only. No, this approach makes assumptions about the datamodel that a viewing/editing tool really should not be making. I think for now, I'm going to stick with simply relying on the the fields to be auto-generated. Cheers, Kevin On 9/4/2010 1:41 AM, Rahkonen Jukka wrote: > Hi, > > How are you going to deal with inserts? And have you considered supporting > also other databases than PostGIS (Oracle, Spatialite)? I have been dealing > with WFS-T against Oracle and I know that inserts are the most tricky part, > especially with Oracle. But it may be tricky even with PostGIS if table has a > combined primary key. > > Perhaps the not-so-recommended Geoserver way could be used? Geoserver selects > max(ID) in the beginning of insert, and feeds in ID=(max(ID)+1). It is not > recommended because it is not reliable at all if there are many users doing > inserts at the same time. The better way is to use triggers but it goes more > complicated. > > -Jukka Rahkonen- > -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Selectionstyle Patch
Hi Landon, sorry for my delay, but my internet connection was down at the weekend :-( I've done the german and english translation in jump_de and jump_en.properties. Matthias > I'll see if I can take a look at the English I18N file. Did you have > English translations of the German words I can use? Or is the English > file already done? > > The Sunburned Surveyor > > On Fri, Sep 3, 2010 at 6:12 AM, Larry Becker wrote: > >> Thanks for your patience Matthias. Selection Style is a nice addition to >> OJ. >> >> regards, >> >> Larry >> >> On Fri, Sep 3, 2010 at 2:18 AM, Matthias Scholz wrote: >> >>> Hi, >>> >>> just now I have commited my selection style changes. Thanks to Larry for >>> his help! >>> It would be nice if the language contributors can update the language >>> files. I've only changed the german translation. The following keys must >>> be changed: >>> ui.plugin.OptionsPlugIn.selection-style >>> ui.SelectionStyllingOptionsPanel.LineColor >>> ui.SelectionStyllingOptionsPanel.PointStyle >>> ui.SelectionStyllingOptionsPanel.PointSize >>> ui.SelectionStyllingOptionsPanel.RestoreDefaultsSettings >>> Please take look at the default jump.properties file. >>> >>> Now OJ have a new panel in the options, from where you can change the >>> settings. >>> >>> Regards >>> >>> Matthias >>> >>> >>> -- >>> This SF.net Dev2Dev email is sponsored by: >>> >>> Show off your parallel programming skills. >>> Enter the Intel(R) Threading Challenge 2010. >>> http://p.sf.net/sfu/intel-thread-sfd >>> ___ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >> -- >> This SF.net Dev2Dev email is sponsored by: >> >> Show off your parallel programming skills. >> Enter the Intel(R) Threading Challenge 2010. >> http://p.sf.net/sfu/intel-thread-sfd >> ___ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> >> > > -- > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Charset choise
Hi Michaël, hi all other, sorry for my delay, but my internet connection was down at the weekend, so it was not possible for me to answer or commit any changes. 1. Charset setting for filednames I've seen, that my enhanchements do not include the fieldnames in the dbf header. To integrate the charset stuff for the filednames I had to change some method signatures (add Charset parameter). Because I do not know how is using the methods, I have build the "old" methods as a wrapper which is calling the "new" one with charset option. I hope thats the right way. As example please see the constructor of org.geotools.dbffile.DbfFile. In DbfFile I've removed the get/setCharset methods because the filednames will be read within the constructor(DbfFile->init->for() loop at the end). And to read the fieldnames with one charset, then set an other one and read the data with that makes no sense for me. 2. Save dataset as shapefile with charset settings If we have an option while opening, we should have an equivalent one while saving. But the save mechanism is not so simple as the open wizard. So there are more code changes required. In org.geotools.dbffile.DbfFileWriter added charset stuff. In com.vividsolutions.jump.workbench.datasource.InstallStandardDataSourceQueryChoosersPlugIn.addFileDataSourceQueryChoosers() I've added a combobox for the charset if we saving shapefiles. I don't if this is the right place or if this is a little bit ugly. In the future we should go a uniform way for such options. For GML as example we have a separate installer plugin. I would suggest a kind of save wizard(as the open file wizard and FileLoader options) where you can add simply options for save. 3. org.openjump.OpenJumpConfiguration I've changed the key of the charset option. Now we use a non localized key. This is better for saving in the project configuration. On the other hand in org.openjump.core.ui.plugin.file.open.SelectFileOptionsPanel.addIndividualSettingsFields() there is a nice mechanism for translating the option keys. But this was not used/activated in line 168. I hope no one have a problem with the change in line 168. As a consquence I had to change the language key from "org.openjump.core.ui.plugin.file.charset" to "org.openjump.core.ui.io.file.DataSourceFileLayerLoader.charset". 4. org.openjump.core.ui.plugin.layer.LayerPropertiesPlugIn I've added the view of the charset settings, if the datasource is a shapefile. 5. com.vividsolutions.jump.io.ShapefileReader In the read() method I've moved back the charset code outsite the "if ( mydbf == null )" brunch, for reading the fieldnames with charset. The new code is "non-dbf" save too. I do not know before, that Shape files without Dbf files are possible. This was a new fact for me ;-) The getDbfFile() method I had to change for reading the fieldnames with a charset. 6. Save/restore charset setting to/from project configuration I had nothing to do for that. The Option mechanism for FileLayerLoaders in combination with the OpenFileWizard do this automatically, if you add an Option :-) Regards Matthias > Hi Matthias, > > I just moved the setCharset statement of ShapefileReader after the dbf > != null test, because otherwise it broke the reading of shapefiles > without dbf (which is not a very common case, but still a nice feature) > If you want to check, I just commited. > > Michaël > > Le 03/09/2010 23:50, Michaël Michaud a écrit : > >>Hi Matthias, >> >> >>> Can you give me some information about how it is supposed to work. Am I >>> supposed to get a panel with a charset option for any shapefile loading ? >>> >> Sorry for that question, I did not launch the new compiled version. I >> know get the charset choice dialog. >> >> Thanks, >> >> Michaël >> >> >>> 2) if we want to keep java 5 compatibility, you have to use new >>> String(byte[], int, int, String) instead of new String(byte[], int, int, >>> Charset) on line 264 >>> >>> 3) about your proposition of saving the charset in the project when >>> different from default jvm charset : Seems a good idea to me. >>> >>> Michaël >>> >>> Le 03/09/2010 20:34, Matthias Scholz a écrit : >>> Hi, sorry my mistake. I have it only tested with open and open recent ;-) In the SVN it is fixed for the first time, but there is a general question and I want to hear the other developers/users. If I open a shapefile with a special charset setting for the first time, it would be logic for me, if we save the charset setting for this file in the project. So if the user opens this file again with the project, the file will be opened with the same charset. Should I implement this or have anyone an other suggestion? Regards Matthias > Nice feature, but it is going to take a little more work. It > currently breaks shapefile loading from a project file and the > lright-cli
Re: [JPP-Devel] wishlist
I'm programmatically invoking a refresh on the layer - any data currently in the bounding box of the viewport is reloaded from the datastore ... which includes the newly inserted feature. I suppose I could be smarter about this and reload all features whose bounding boxes match the bounding box of the feature just inserted. Then I'd filter all features already in the client's cache, thereby adding one new feature to the FeatureCollection ... but a complete layer refresh is far easier. :) -- Kevin On 9/6/2010 6:31 AM, Rahkonen Jukka wrote: > Hi, > > One further question: How are you going to get the ID of the newly inserted > feature back to OpenJUMP side? > > -Jukka- > -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] question about getUltimateWrappee()
The FeatureCollectionWrapper.getUltimateWrappee() looks like this:
public FeatureCollection getUltimateWrappee() {
FeatureCollection currentWrappee = fc;
while (currentWrappee instanceof FeatureCollectionWrapper) {
currentWrappee = ((FeatureCollectionWrapper) currentWrappee).fc;
}
return currentWrappee;
}
http://jump-pilot.svn.sourceforge.net/viewvc/jump-pilot/core/trunk/src/com/vividsolutions/jump/feature/FeatureCollectionWrapper.java?revision=859&view=markup#l66
Is there a reason line 66 references .fc directly instead of .getWrappee() ?
For me this currently returns the wrong answer. In the case of a
CachingFeatureCollection, there are actually two FeatureCollections: the
actual wrapped FC and a cached FC (a potentially small subset of the
wrapped FC). So, in this case, .fc references the cached FC, which is
not the FC I'm actually after.
I've overridden CachingFeatureCollection.getWrappee() in a custom
variant to return the actual wrapped FC, which in my case is a custom
DataStoreFeatureCollection that mimics a database table, not the cached
FC subset.
-- Kevin
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
