[JPP-Devel] Fwd: Re: [jump-pilot:code] [r4201] - edso: AttributType ported from Kosmo which supports much more data types, incl. LONG

[Michael Michaud]

Hey Ede,

You made a big change on AttributeType class last thursday,
It's a very interesting change with a lot of potential, but my
concern is how much code it will break, and how much time
it will take to upgrade all the code depending on this class.

New data types you inroduced are already available in Edit
Schema plugin, but many drivers/plugin are not ready to
manage these new types.
From my point of view, this is the kind of change which may
justify to create a new branch as it may break current code
for an undetermined laps of time.

What do you think ? Is it an intentional commit ?
Are you aware of all the dependencies ?

Michaël


AttributType ported from Kosmo which supports much more data types, 
incl. LONG http://sourceforge.net/p/jump-pilot/code/4201/ 





Sent from sourceforge.net because you indicated interest in 
https://sourceforge.net/p/jump-pilot/code/ 



To unsubscribe from further messages, please visit 
https://sourceforge.net/auth/subscriptions/ 







--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/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] WFS plugin revived

[edgar . soldin]

ok,

i just had a look at the currently defunct WFSPlugin in our svn and brought it 
back to life. i am going to integrate it into CORE for easier maintenance, but 
it'll need 6.5MB dependencies. so we have two possibilities
A. add these to CORE 20MB + 6.5 = 26MB
B. add them only to PLUS and the plugin becomes active only on PLUS

NOTE1: i had a look at Kosmo WFS (which is WFSPlugin evolved within Kosmo) and 
decided porting it was too complex, lot's of srs code and dependencies, 
generally not needed by us.

NOTE2: yes, WFSPlugin could stay an extension, but this would mean overhead 
(building in another project, packaging, updating PLUS) which i am not willing 
to take care of. especially if we plan to enhance and do some more work on it.

opinions please ..ede

PS: actually i can live with 7MB more, but that's just me.)

 

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/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] Fwd: Re: [jump-pilot:code] [r4201] - edso: AttributType ported from Kosmo which supports much more data types, incl. LONG

[edgar . soldin]

On 21.12.2014 17:07, Michael Michaud wrote:
> Hey Ede,
> 
> You made a big change on AttributeType class last thursday,
> It's a very interesting change with a lot of potential, but my
> concern is how much code it will break, and how much time
> it will take to upgrade all the code depending on this class.

valid concern
 
> New data types you inroduced are already available in Edit
> Schema plugin, but many drivers/plugin are not ready to
> manage these new types.

that was my intention and we have to start somewhere. the commit as such does 
not break a thing. when people start using the new attribute types and trun 
into errors we can start fixing them.

> From my point of view, this is the kind of change which may
> justify to create a new branch 

not again ;).. we are simply too few devs to maintain anymore than one proper 
branch

>as it may break current code

which code do you have in mind?

> for an undetermined laps of time.

shouldn't it break nothing? the "old" attribute types will continue to work as 
good as before. readers will probably still use the old datatypes and _only_ if 
the user switches the change will become effective, non?

> 
> What do you think ? Is it an intentional commit ?

yes. a first step, nothing more, nothing less.

> Are you aware of all the dependencies ?

the topic comes up from time to time, but we shy away from it. so why not start?

do you have an issue at hand, that breaks OJ's general usability because of 
this commit?

..ede


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/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] WFS plugin revived

[Michael Michaud]

Hi Ede,

> i just had a look at the currently defunct WFSPlugin in our svn and brought 
> it back to life. i am going to integrate it into CORE for easier maintenance, 
> but it'll need 6.5MB dependencies. so we have two possibilities
> A. add these to CORE 20MB + 6.5 = 26MB
> B. add them only to PLUS and the plugin becomes active only on PLUS
Geat news !

I think it should take place in PLUS if it is not much more work, but I can
accept it in CORE if several users prefer to have it in CORE.
The biggest dependencies seems to be degree/crs, then
degree/ogcwebservices (wms...). I'll have a look to check if we can plug
WFS on the new CTS and get rid of deegree/crs, but it may be difficult.
I'm not a W*S expert as Jukka, but do you know if the WFS version used
by the plugin is already uptodate. Current degree project is at version
3.3.13 (plugin uses version 2 code).
Anyway, including WFS plugin as is would be a major step.

Michaël
>
> NOTE1: i had a look at Kosmo WFS (which is WFSPlugin evolved within Kosmo) 
> and decided porting it was too complex, lot's of srs code and dependencies, 
> generally not needed by us.
>
> NOTE2: yes, WFSPlugin could stay an extension, but this would mean overhead 
> (building in another project, packaging, updating PLUS) which i am not 
> willing to take care of. especially if we plan to enhance and do some more 
> work on it.
>
> opinions please ..ede
>
> PS: actually i can live with 7MB more, but that's just me.)
>
>   
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/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] WFS plugin revived

[Giuseppe Aruta]

Hi Ede,
I think that having a working WFS plugin is an important goal for OpenJUMP.
I am much more interested to have it into CORE. 6.5 Mb is noy a big
quantity.

Peppe

2014-12-21 17:13 GMT+01:00 :

> ok,
>
> i just had a look at the currently defunct WFSPlugin in our svn and
> brought it back to life. i am going to integrate it into CORE for easier
> maintenance, but it'll need 6.5MB dependencies. so we have two possibilities
> A. add these to CORE 20MB + 6.5 = 26MB
> B. add them only to PLUS and the plugin becomes active only on PLUS
>
> NOTE1: i had a look at Kosmo WFS (which is WFSPlugin evolved within Kosmo)
> and decided porting it was too complex, lot's of srs code and dependencies,
> generally not needed by us.
>
> NOTE2: yes, WFSPlugin could stay an extension, but this would mean
> overhead (building in another project, packaging, updating PLUS) which i am
> not willing to take care of. especially if we plan to enhance and do some
> more work on it.
>
> opinions please ..ede
>
> PS: actually i can live with 7MB more, but that's just me.)
>
>
>
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/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] Fwd: Re: [jump-pilot:code] [r4201] - edso: AttributType ported from Kosmo which supports much more data types, incl. LONG

[Michael Michaud]

Hi,
>
>> You made a big change on AttributeType class last thursday,
>> It's a very interesting change with a lot of potential, but my
>> concern is how much code it will break, and how much time
>> it will take to upgrade all the code depending on this class.
> valid concern
>   
>> New data types you inroduced are already available in Edit
>> Schema plugin, but many drivers/plugin are not ready to
>> manage these new types.
> that was my intention and we have to start somewhere. the commit as such does 
> not break a thing. when people start using the new attribute types and trun 
> into errors we can start fixing them.
>
>>  From my point of view, this is the kind of change which may
>> justify to create a new branch
> not again ;).. we are simply too few devs to maintain anymore than one proper 
> branch
>
>> as it may break current code
> which code do you have in mind?
Just create a new layer with a boolean type, edit a feature to set the 
boolean attribute to true or false,
you are done, you can no more edit the schema, you can no more save the 
dataset to a shapefile...

Pieces of code which will probably be broken as soon as new attributes 
values will be used :
drivers : shapefile driver, postgis driver, extension drivers...
tools based on attribute like attribute agregators, queries...
Just checked : more than 100 classes use AttributeType class.
It does not mean all have to be fixed, but I would say most of them will 
have to.
>> for an undetermined laps of time.
> shouldn't it break nothing? the "old" attribute types will continue to work 
> as good as before. readers will probably still use the old datatypes and 
> _only_ if the user switches the change will become effective, non?
Yes I think that OJ should continue working as before as long as the 
user does not use new attribute types.

I think we could hide new attribute types in stable releases as long as 
major fixes have to be done.
>
>> What do you think ? Is it an intentional commit ?
> yes. a first step, nothing more, nothing less.
>
>> Are you aware of all the dependencies ?
> the topic comes up from time to time, but we shy away from it. so why not 
> start?
>
> do you have an issue at hand, that breaks OJ's general usability because of 
> this commit?
OK, nothing impossible. Just think it should be evaluated as soon as 
possible, because
if we work in the trunc, when we will have upgraded tens of classes, 
we'll have to finish
the work ;-)
Also I have seen that most of database types have been included by 
kosmo, even datatypes
which have the same internal representation (decimal/numeric/bigdecimal).

I think we can just wonder why we add these types ? I think that some 
data types
really add capabilities (boolean, long), but I like simplicity and I 
wouldn't like
to add 10 new types just because it's as cheap as adding 2 of them.

My 2 cents,

Michaël


>
> ..ede
>
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/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] WFS plugin revived

[Stefan Steiniger]

I would prefer it in PLUS rather than Core, because I don't think there 
are so many out there that would use a WFS daily.

I am just thinking that 6MB does not sound a lot... but in other parts 
of the world downling another 6MB may make a difference.

cheers,
stefan

Am 21.12.14 14:23, schrieb Giuseppe Aruta:
> Hi Ede,
> I think that having a working WFS plugin is an important goal for
> OpenJUMP. I am much more interested to have it into CORE. 6.5 Mb is noy
> a big quantity.
>
> Peppe
>
> 2014-12-21 17:13 GMT+01:00  >:
>
> ok,
>
> i just had a look at the currently defunct WFSPlugin in our svn and
> brought it back to life. i am going to integrate it into CORE for
> easier maintenance, but it'll need 6.5MB dependencies. so we have
> two possibilities
> A. add these to CORE 20MB + 6.5 = 26MB
> B. add them only to PLUS and the plugin becomes active only on PLUS
>
> NOTE1: i had a look at Kosmo WFS (which is WFSPlugin evolved within
> Kosmo) and decided porting it was too complex, lot's of srs code and
> dependencies, generally not needed by us.
>
> NOTE2: yes, WFSPlugin could stay an extension, but this would mean
> overhead (building in another project, packaging, updating PLUS)
> which i am not willing to take care of. especially if we plan to
> enhance and do some more work on it.
>
> opinions please ..ede
>
> PS: actually i can live with 7MB more, but that's just me.)
>
>
>
> 
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration &
> more
> Get technology previously reserved for billion-dollar corporations, FREE
> 
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
>
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>
>
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/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] WFS plugin revived

[edgar . soldin]

On 21.12.2014 17:51, Michael Michaud wrote:
> Hi Ede,
> 
>> i just had a look at the currently defunct WFSPlugin in our svn and brought 
>> it back to life. i am going to integrate it into CORE for easier 
>> maintenance, but it'll need 6.5MB dependencies. so we have two possibilities
>> A. add these to CORE 20MB + 6.5 = 26MB
>> B. add them only to PLUS and the plugin becomes active only on PLUS
> Geat news !

'geat' actually exists ;)
 http://en.wikipedia.org/wiki/Gaut
 
> I think it should take place in PLUS if it is not much more work, but I can
> accept it in CORE if several users prefer to have it in CORE.

if you are willing to maintain it as an extension, you are welcome. generally, 
having WMS in CORE, it'd make sense to have WFS there too.

we can easily maintain the plugin within CORE, but keep the dependencies in 
PLUS, like we do already for
- SVN plugin
- some image readers
...

> The biggest dependencies seems to be degree/crs, then

yeah 5.5MB.. that's some.

thought about stripping only the parts we need for WFS, but then we'd have to 
keep them updated ourselfs. and here comes the man-power argument, again!

> degree/ogcwebservices (wms...). I'll have a look to check if we can plug
> WFS on the new CTS and get rid of deegree/crs, but it may be difficult.

no way. it uses quite some degree2 code, which extends to more than crs stuff.

> I'm not a W*S expert as Jukka, but do you know if the WFS version used
> by the plugin is already uptodate. 

not at all, we (especially Jukka;) have to check it out and then look into 
Kosmo for hints on how to implement it, in case something is amiss.

>Current degree project is at version
> 3.3.13 (plugin uses version 2 code).

which still seems to be maintained
 https://github.com/deegree/deegree2-base
for some desktop utility they provide afaiu.

not sure if it is worth the headache to port to deegree3 if we use a maintained 
library.

> Anyway, including WFS plugin as is would be a major step.

dunno ("ce est gis?":), just thought i might give it a go ;).. ede

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/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] Fwd: Re: [jump-pilot:code] [r4201] - edso: AttributType ported from Kosmo which supports much more data types, incl. LONG

[edgar . soldin]

On 21.12.2014 18:37, Michael Michaud wrote:
> Hi,
>>
>>> You made a big change on AttributeType class last thursday,
>>> It's a very interesting change with a lot of potential, but my
>>> concern is how much code it will break, and how much time
>>> it will take to upgrade all the code depending on this class.
>> valid concern
>>   
>>> New data types you inroduced are already available in Edit
>>> Schema plugin, but many drivers/plugin are not ready to
>>> manage these new types.
>> that was my intention and we have to start somewhere. the commit as such 
>> does not break a thing. when people start using the new attribute types and 
>> trun into errors we can start fixing them.
>>
>>>  From my point of view, this is the kind of change which may
>>> justify to create a new branch
>> not again ;).. we are simply too few devs to maintain anymore than one 
>> proper branch
>>
>>> as it may break current code
>> which code do you have in mind?
> Just create a new layer with a boolean type, edit a feature to set the 
> boolean attribute to true or false,
> you are done, you can no more edit the schema, you can no more save the 
> dataset to a shapefile...

that should be easy to fix.. shouldn't it?

> Pieces of code which will probably be broken as soon as new attributes 
> values will be used :
> drivers : shapefile driver, postgis driver, extension drivers...
> tools based on attribute like attribute agregators, queries...
> Just checked : more than 100 classes use AttributeType class.
> It does not mean all have to be fixed, but I would say most of them will 
> have to.

totally correct, and they will still be - unless we start somewhere

>>> for an undetermined laps of time.
>> shouldn't it break nothing? the "old" attribute types will continue to work 
>> as good as before. readers will probably still use the old datatypes and 
>> _only_ if the user switches the change will become effective, non?
> Yes I think that OJ should continue working as before as long as the 
> user does not use new attribute types.

which you did in the example above ;)

> I think we could hide new attribute types in stable releases as long as 
> major fixes have to be done.

yeah, thought about that too. we could enable types in a configuration panel, 
for power users to activate.

problem though, how many power users are there to actually use it and report 
issues?

>>> What do you think ? Is it an intentional commit ?
>> yes. a first step, nothing more, nothing less.
>>
>>> Are you aware of all the dependencies ?
>> the topic comes up from time to time, but we shy away from it. so why not 
>> start?
>>
>> do you have an issue at hand, that breaks OJ's general usability because of 
>> this commit?
> OK, nothing impossible. Just think it should be evaluated as soon as 
> possible, because
> if we work in the trunc, when we will have upgraded tens of classes, 
> we'll have to finish
> the work ;-)

we are aiming for an ideal, which in the true sense of the word, cannot be 
reached at all. so let's simply try the possible.

> Also I have seen that most of database types have been included by 
> kosmo, even datatypes
> which have the same internal representation (decimal/numeric/bigdecimal).

yeah, but bigdecimal can hold greater numbers
 
> I think we can just wonder why we add these types ? I think that some 
> data types
> really add capabilities (boolean, long), but I like simplicity and I 
> wouldn't like
> to add 10 new types just because it's as cheap as adding 2 of them.

sure, if they are truly identical we might throw them out. do as you please.

..ede

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/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] Re WFS plugin revived

[Rahkonen Jukka (Tike)]

Some quick comments, may be inaccurate:

deegree2 is not really maintained. Deegree3 is much more complicated because it 
aims to support all INSPIRE specialities and applications schemas (and WFS 
v.2.0.0 and 2.0.2) which go beyound the simple feature model. It may be that 
doing the simple things with deegree3 is still simple even it supports also 
doing complicated things.

The desktop application iGeoDesktop seems to be dead or at least very close.

Even if deegree2 does not get bug fixes and new features but we can use it with 
good success with WFS 1.0.0 and 1.1.0 then the plugin is still usable for at 
least some years.

Plugin version 1.0.0 had a nice editable text area which showed the real POST 
message that was generated by the plugin. That was removed from 1.1.0 if I 
remember right. That would be nice to get back.

Kosmo has very good WFS client which handles also many oddidies in different 
WFS servers. That must make code much more complicated. I would say that if 
OpenJUMP WFS works well with GeoServer then it would be enough and support for 
other brands would be nice extra.

I would like to test this new WFS reader (which I would pack to OJ PLUS) and I 
have some servers to test with.

-Jukka Rahkonen-

edgar.soldin wrote:

On 21.12.2014 17:51, Michael Michaud wrote:
> Hi Ede,
>
>> i just had a look at the currently defunct WFSPlugin in our svn and brought 
>> it back to life. i am going to integrate it into CORE for easier 
>> maintenance, but it'll need 6.5MB dependencies. so we have two possibilities
>> A. add these to CORE 20MB + 6.5 = 26MB
>> B. add them only to PLUS and the plugin becomes active only on PLUS
> Geat news !

'geat' actually exists ;)
 http://en.wikipedia.org/wiki/Gaut

> I think it should take place in PLUS if it is not much more work, but I can
> accept it in CORE if several users prefer to have it in CORE.

if you are willing to maintain it as an extension, you are welcome. generally, 
having WMS in CORE, it'd make sense to have WFS there too.

we can easily maintain the plugin within CORE, but keep the dependencies in 
PLUS, like we do already for
- SVN plugin
- some image readers
...

> The biggest dependencies seems to be degree/crs, then

yeah 5.5MB.. that's some.

thought about stripping only the parts we need for WFS, but then we'd have to 
keep them updated ourselfs. and here comes the man-power argument, again!

> degree/ogcwebservices (wms...). I'll have a look to check if we can plug
> WFS on the new CTS and get rid of deegree/crs, but it may be difficult.

no way. it uses quite some degree2 code, which extends to more than crs stuff.

> I'm not a W*S expert as Jukka, but do you know if the WFS version used
> by the plugin is already uptodate.

not at all, we (especially Jukka;) have to check it out and then look into 
Kosmo for hints on how to implement it, in case something is amiss.

>Current degree project is at version
> 3.3.13 (plugin uses version 2 code).

which still seems to be maintained
 https://github.com/deegree/deegree2-base
for some desktop utility they provide afaiu.

not sure if it is worth the headache to port to deegree3 if we use a maintained 
library.

> Anyway, including WFS plugin as is would be a major step.

dunno ("ce est gis?":), just thought i might give it a go ;).. ede

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/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] Fwd: Re: [jump-pilot:code] [r4201] - edso: AttributType ported from Kosmo which supports much more data types, incl. LONG

[Michael Michaud]

Hi,



You made a big change on AttributeType class last thursday,
It's a very interesting change with a lot of potential, but my
concern is how much code it will break, and how much time
it will take to upgrade all the code depending on this class.

valid concern
   

New data types you inroduced are already available in Edit
Schema plugin, but many drivers/plugin are not ready to
manage these new types.

that was my intention and we have to start somewhere. the commit as such does 
not break a thing. when people start using the new attribute types and trun 
into errors we can start fixing them.


  From my point of view, this is the kind of change which may
justify to create a new branch

not again ;).. we are simply too few devs to maintain anymore than one proper 
branch


as it may break current code

which code do you have in mind?

Just create a new layer with a boolean type, edit a feature to set the
boolean attribute to true or false,
you are done, you can no more edit the schema, you can no more save the
dataset to a shapefile...

that should be easy to fix.. shouldn't it?

Not that easy :
Edit Schema : it includes capabilities to cast attributes from a data 
type to another.

The more data types, the more rules to define
Shapefile/Dbf : dbf specification is weird (numeric as text with length 
+ decial places,

date as text, boolean as case insensitive text...)

Pieces of code which will probably be broken as soon as new attributes
values will be used :
drivers : shapefile driver, postgis driver, extension drivers...
tools based on attribute like attribute agregators, queries...
Just checked : more than 100 classes use AttributeType class.
It does not mean all have to be fixed, but I would say most of them will
have to.

totally correct, and they will still be - unless we start somewhere

I think priority n°1 is shapefile



for an undetermined laps of time.

shouldn't it break nothing? the "old" attribute types will continue to work as 
good as before. readers will probably still use the old datatypes and _only_ if the user 
switches the change will become effective, non?

Yes I think that OJ should continue working as before as long as the
user does not use new attribute types.

which you did in the example above ;)


I think we could hide new attribute types in stable releases as long as
major fixes have to be done.

yeah, thought about that too. we could enable types in a configuration panel, 
for power users to activate.

problem though, how many power users are there to actually use it and report 
issues?
Not much, but we can discover easily many places to fix before letting 
more users help us discover corner cases.



What do you think ? Is it an intentional commit ?

yes. a first step, nothing more, nothing less.


Are you aware of all the dependencies ?

the topic comes up from time to time, but we shy away from it. so why not start?

do you have an issue at hand, that breaks OJ's general usability because of 
this commit?

OK, nothing impossible. Just think it should be evaluated as soon as
possible, because
if we work in the trunc, when we will have upgraded tens of classes,
we'll have to finish
the work ;-)

we are aiming for an ideal, which in the true sense of the word, cannot be 
reached at all. so let's simply try the possible.


Also I have seen that most of database types have been included by
kosmo, even datatypes
which have the same internal representation (decimal/numeric/bigdecimal).

yeah, but bigdecimal can hold greater numbers
Yes but bigdecimal, numeric and decimal have the same internal 
representation (bigdecimal).

See after.



I think we can just wonder why we add these types ? I think that some
data types
really add capabilities (boolean, long), but I like simplicity and I
wouldn't like
to add 10 new types just because it's as cheap as adding 2 of them.

sure, if they are truly identical we might throw them out. do as you please.
I started a document to sum up problems concerning data type 
transposition (here attached).
First column contains OpenJUMP 1.8 AttributeType and second column 
contains Kosmo AttributeTypes.


My suggestion is to keep the green ones.
There are many AttributeTypes with the same java internal representation 
in kosmo.
I don't say they are useless. I think they have been added in order to 
match more precisely
database data types (which makes it possible to keep track of true data 
types used in the

database in certain circumstances)
My opinion is that it adds confusion for a basic usage of OpenJUMP, but 
let's submit

the discussion to the group.
I did not keep tinyint and float because I think they are relics of old 
times (16 bits processors)
I hesitate for time and timestamp as managing / formatting date / times 
is often much troubles

and current Dates can already store timestamps.

Michaël


..ede

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BI