You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov> on 2013/02/15 17:44:56 UTC
FW: NOAA Meetup
Guys, I need to prepare a short talk on Apache SIS for this NOAA meetup next week.
I'm going to do it over Skype. Would love any input on slides or material you'd like me to include.
Thanks!
Cheers,
Chris
From: Ilya Rosenfeld <ir...@opengeo.org>>
Date: Friday, February 15, 2013 8:43 AM
To: jpluser <ch...@jpl.nasa.gov>>
Subject: Re: NOAA Meetup
From: Ilya Rosenfeld <ir...@opengeo.org>>
Date: Thursday, January 24, 2013 5:59 PM
To: jpluser <ch...@jpl.nasa.gov>>
Subject: NOAA Meetup
Hey Chris - FYI: http://www.meetup.com/GFOSS-NOAA/
Feel free to join and participate! We're doing our next meetup in the DC Area on Feb 20th but will have a telecon going. It'd be great to get you piped into this.
Best,
-Ilya
Re: NOAA Meetup
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Thanks Adam, makes sense.
Guys: another thing to note. Fast Feather tracks just opened up at
ApacheCon NA 2013. It's an opportunity for a short, but meaningful talk:
http://s.apache.org/BqE
Maybe we should do a Fast Feather on SIS? Any interest?
Cheers,
Chris
On 2/16/13 12:42 PM, "Adam Estrada" <es...@gmail.com> wrote:
>Chris,
>
>I think that it is important to note that what is currently being worked
>on not only helps to promote interoperability, its helping to define it
>by adhering so rigorously to ISO and OGC standards. Your's and Martin's
>involvement with the OGC GeoAPI working group is huge for the geospatial
>community because you can help to promote the use of these standards
>across all communities. I really believe that the key takeaway should
>resemble something like this.
>
>Does anyone else have anything else to weigh in?
>
>Thanks!
>Adam
>
>
>On Feb 15, 2013, at 11:44 AM, Mattmann, Chris A (388J) wrote:
>
>> Guys, I need to prepare a short talk on Apache SIS for this NOAA meetup
>>next week.
>>
>> I'm going to do it over Skype. Would love any input on slides or
>>material you'd like me to include.
>>
>> Thanks!
>>
>> Cheers,
>> Chris
>>
>> From: Ilya Rosenfeld
>><ir...@opengeo.org>>
>> Date: Friday, February 15, 2013 8:43 AM
>> To: jpluser
>><ch...@jpl.nasa.gov>>
>> Subject: Re: NOAA Meetup
>>
>> From: Ilya Rosenfeld
>><ir...@opengeo.org>>
>> Date: Thursday, January 24, 2013 5:59 PM
>> To: jpluser
>><ch...@jpl.nasa.gov>>
>> Subject: NOAA Meetup
>>
>> Hey Chris - FYI: http://www.meetup.com/GFOSS-NOAA/
>>
>> Feel free to join and participate! We're doing our next meetup in the
>>DC Area on Feb 20th but will have a telecon going. It'd be great to get
>>you piped into this.
>>
>> Best,
>> -Ilya
>>
>>
>
Re: NOAA Meetup
Posted by Adam Estrada <es...@gmail.com>.
Chris,
I think that it is important to note that what is currently being worked on not only helps to promote interoperability, its helping to define it by adhering so rigorously to ISO and OGC standards. Your's and Martin's involvement with the OGC GeoAPI working group is huge for the geospatial community because you can help to promote the use of these standards across all communities. I really believe that the key takeaway should resemble something like this.
Does anyone else have anything else to weigh in?
Thanks!
Adam
On Feb 15, 2013, at 11:44 AM, Mattmann, Chris A (388J) wrote:
> Guys, I need to prepare a short talk on Apache SIS for this NOAA meetup next week.
>
> I'm going to do it over Skype. Would love any input on slides or material you'd like me to include.
>
> Thanks!
>
> Cheers,
> Chris
>
> From: Ilya Rosenfeld <ir...@opengeo.org>>
> Date: Friday, February 15, 2013 8:43 AM
> To: jpluser <ch...@jpl.nasa.gov>>
> Subject: Re: NOAA Meetup
>
> From: Ilya Rosenfeld <ir...@opengeo.org>>
> Date: Thursday, January 24, 2013 5:59 PM
> To: jpluser <ch...@jpl.nasa.gov>>
> Subject: NOAA Meetup
>
> Hey Chris - FYI: http://www.meetup.com/GFOSS-NOAA/
>
> Feel free to join and participate! We're doing our next meetup in the DC Area on Feb 20th but will have a telecon going. It'd be great to get you piped into this.
>
> Best,
> -Ilya
>
>
Re: NOAA Meetup
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Martin, Adam, you both have the right goals. We're doing fine.
At Apache we take small, incremental, easily reversible steps. Grand,
sweeping change, and/o support for Feature Foo, etc., is usually not
happen overnight, and/or happen in a week or two weeks.
I would expect a provenance of:
1. I'm interested in some BiG feature X
A. file JIRA issue with intent
B. create wiki pages
C. create consensus around the approach idea
D. divide into small steps
2. Foreach s in steps
A. File JIRA issue perhaps as sub-issue to 1A
B. Demonstrate incremental progress with patches, either put up on
http://reviews.apache.org, and/or JIRA or both
C. Discuss on 2B
D. Update 1B
E. iterate
F. through consensus (lazy or not), commit B
3. Make potentially incremental releases while including parts or all of 1
4. Arrive eventually in some release Y at 1
Martin you have been doing a great job of all of the above. That's how we
get stuff done around here at the ASF.
Can we elaborate the missing steps in order, with some specific feedback
for example to getting to WMS? If we could, then I or others could try and
bite off at least the ones we're familiar with to help out. But request
for feature X really needs to be driven by the people that are interested
in X and have the time/desire to get there, e.g., those willing to
"scratch the itch".
HTH explains how it works.
Cheers,
Chris
On 2/17/13 8:21 AM, "Martin Desruisseaux"
<ma...@geomatys.fr> wrote:
>Hello Adam
>
>To make a large library more accessible to neogeographers, maybe we
>would need to hide lot of methods and classes in order to keep only the
>most important one visible in the javadoc. A lot of classes are internal
>mechanics from neogeographers perspective, and would become useful
>public API only for more advanced users. However we face two difficulties:
>
> * I'm not aware of any way in current Javadoc technology to flag a
> method or class as "advanced API" to be show only when the user
> browse the Javadoc in "advanced" mode. I think that such
> functionality is under consideration at Oracle, but I don't know
> if/when it would appear.
> * It is difficult to define what is the "core API" to show to
> neogeographers. For example the ISO 19115 standard (metadata), which
> defines about 100 classes, tried in its 2003 version to define a
> "core metadata" profile with only the few most important classes.
> But in their 2013 revision, they are removing this core profile. The
> reason is that everyone has a different opinion of what "core" is.
>
>
>Nevertheless the need is still present and other peoples have expressed
>it. When OGC accepted GeoAPI 3.0.0 as a standard, the OGC Architecture
>Board (OAB) told us that for the next GeoAPI release (3.1), they will
>require us to define a "core" part of that API. This is one area where
>I'm going to need help on the GeoAPI side: among the 271 classes or
>interfaces in GeoAPI 3.0.0, which one should be considered "core"? That
>would define indirectly which SIS classes would be considered core API.
>
>But even if we define core API, we are still facing the problem of how
>to hide non-core API from javadoc. I have no technical solution to that
>question yet... (but I have hope that JDK9 will help us - note that it
>doesn't mean that users have to use JDK9; we would just use JDK9 for
>generating the javadoc).
>
>
>On the question about roadmap toward something usable (WMS or desktop
>application), I have to admit that the classes committed up to date are
>of little direct use in the short term. To make a WMS, we need a
>renderer engine, which needs geometry objects, which need referencing
>framework, which need metadata... If we take a short-cut, for example by
>omitting the referencing framework for now, I find difficult to
>reintroduce referencing awareness in existing code later. We are facing
>a similar situation in our existing WMS server: it doesn't behave well
>with data crossing the anti-meridian. We have made some attempts to fix
>that problem in existing code, but the problem spread in every corners
>of the libraries (we have to check every places where an Envelope is
>used). This is one example of goal which seem easier to address from the
>beginning of a project than to try to fix in existing code.
>
>So it is difficult for me to give a firm roadmap for WMS... The code
>exists, but I would like to commit clean code to SIS with known issues
>solved...
>
>In the last week I worked on relatively minor secondary classes (Ranges)
>because I'm facing a problem with the more important classes (XML
>marshalling) for which I didn't found a solution yet: there is
>apparently no way to have good control on the prefixes used in XML
>documents other than sub-classing the
>com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper, which is not
>public API. This is what we did in Geotk, but I'm not sure it is
>acceptable solution for Apache SIS. I can elaborate more in a separated
>thread (but I need to write a test case first for clarifying the
>issue...). But admittedly I should focus more on trying to solve this
>blocking issue.
>
>Regards,
>
> Martin
>
Re: NOAA Meetup
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Adam
To make a large library more accessible to neogeographers, maybe we
would need to hide lot of methods and classes in order to keep only the
most important one visible in the javadoc. A lot of classes are internal
mechanics from neogeographers perspective, and would become useful
public API only for more advanced users. However we face two difficulties:
* I'm not aware of any way in current Javadoc technology to flag a
method or class as "advanced API" to be show only when the user
browse the Javadoc in "advanced" mode. I think that such
functionality is under consideration at Oracle, but I don't know
if/when it would appear.
* It is difficult to define what is the "core API" to show to
neogeographers. For example the ISO 19115 standard (metadata), which
defines about 100 classes, tried in its 2003 version to define a
"core metadata" profile with only the few most important classes.
But in their 2013 revision, they are removing this core profile. The
reason is that everyone has a different opinion of what "core" is.
Nevertheless the need is still present and other peoples have expressed
it. When OGC accepted GeoAPI 3.0.0 as a standard, the OGC Architecture
Board (OAB) told us that for the next GeoAPI release (3.1), they will
require us to define a "core" part of that API. This is one area where
I'm going to need help on the GeoAPI side: among the 271 classes or
interfaces in GeoAPI 3.0.0, which one should be considered "core"? That
would define indirectly which SIS classes would be considered core API.
But even if we define core API, we are still facing the problem of how
to hide non-core API from javadoc. I have no technical solution to that
question yet... (but I have hope that JDK9 will help us - note that it
doesn't mean that users have to use JDK9; we would just use JDK9 for
generating the javadoc).
On the question about roadmap toward something usable (WMS or desktop
application), I have to admit that the classes committed up to date are
of little direct use in the short term. To make a WMS, we need a
renderer engine, which needs geometry objects, which need referencing
framework, which need metadata... If we take a short-cut, for example by
omitting the referencing framework for now, I find difficult to
reintroduce referencing awareness in existing code later. We are facing
a similar situation in our existing WMS server: it doesn't behave well
with data crossing the anti-meridian. We have made some attempts to fix
that problem in existing code, but the problem spread in every corners
of the libraries (we have to check every places where an Envelope is
used). This is one example of goal which seem easier to address from the
beginning of a project than to try to fix in existing code.
So it is difficult for me to give a firm roadmap for WMS... The code
exists, but I would like to commit clean code to SIS with known issues
solved...
In the last week I worked on relatively minor secondary classes (Ranges)
because I'm facing a problem with the more important classes (XML
marshalling) for which I didn't found a solution yet: there is
apparently no way to have good control on the prefixes used in XML
documents other than sub-classing the
com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper, which is not
public API. This is what we did in Geotk, but I'm not sure it is
acceptable solution for Apache SIS. I can elaborate more in a separated
thread (but I need to write a test case first for clarifying the
issue...). But admittedly I should focus more on trying to solve this
blocking issue.
Regards,
Martin
Re: NOAA Meetup
Posted by Adam Estrada <es...@gmail.com>.
Martin,
I don't want to Shanghai this thread but I feel like I need to add my 2 cents here. I firmly believe that it's very valuable to have a toolkit for processing complex scientific data. I like your example of two seemingly different groups of scientists (eg. physicians and oceanographers) being able to work together to map cholera propagation through the use of common data/format standards. Having said that, I also think that there needs to be tools made available for the common user so that they can perform the same (or similar) analysis that the seasoned scientists can. Neogeography[1] is the term I know of that identifies this as the "the usage of geographical techniques and tools used for personal and community activities or for utilization by a non-expert group of users" This is very appealing to a lot of end users who may not have the skills needed to code up a robust solution but also know what problem they need to solve. I would love to have my cake and eat it too meaning that SIS would have both feature rich low level as well as high level tools and libraries that would appeal to all audiences. What is being added now adds to to the lower-level architecture, so what roadmap items can we lay down to start building tools and services on top of SIS for the causal user (eg. [2][3])?
A
[1] http://en.wikipedia.org/wiki/Neogeography
[2] https://issues.apache.org/jira/browse/SIS-67
[3] http://goo.gl/aZyRZ
On Feb 17, 2013, at 9:08 AM, Martin Desruisseaux wrote:
> Hello Chris, Adam and all
>
> Le 15/02/13 17:44, Mattmann, Chris A (388J) a écrit :
>> Guys, I need to prepare a short talk on Apache SIS for this NOAA meetup next week.
>>
>> I'm going to do it over Skype. Would love any input on slides or material you'd like me to include.
>
> I can send you by email some LibreOffice/OpenOffice.org slides that I have. Or maybe there is some space that we can use somewhere for this kind of material? Those slides would surely need to be adapted however.
>
>
> Le 16/02/13 21:42, Adam Estrada a écrit :
>> I think that it is important to note that what is currently being worked on not only helps to promote interoperability, its helping to define it by adhering so rigorously to ISO and OGC standards. Your's and Martin's involvement with the OGC GeoAPI working group is huge for the geospatial community because you can help to promote the use of these standards across all communities. I really believe that the key takeaway should resemble something like this.
>
> I also believe that our efforts in participating to standards are a very important aspect. GeoAPI is one aspect, but hopefully would not be the only one (after all, we still don't know if GeoAPI will succeed). I think that participation to the meteo-oceanography group is also important and seems close to the concern of many SIS members. Actually, I would love to present SIS as a library having a focus on science :-). One real use case that I have see is crossing data from physicians with data from oceanographers, for a study of cholera propagation. Because physicians and oceanographers are two quite different communities, crossing those data without standards is uneasy. The standards required here are more complex than the usual WMS (we need quality and uncertainties estimations, etc.).
>
> An other aspect that we could said is that SIS benefits from the experience gained from the previous projects: we have learn what worked and what have been bad idea. Every class that we port to SIS is an opportunity to revisit it and sometime to simplify it. When a feature seems overly complex, we have the possibility to search in the previous projects how this feature was used. This help us to determine how it can be simplified.
>
> An other reason for revisiting classes one-by-one is that the Java landscape as changed: JavaFX and Android need to be keep in mind, which imply for example to try to isolate Java2D dependencies in dedicated classes. Some factories may be replaced by JSR-330 (dependency injection). Support for supplementary Unicode characters become worthy, since they now include geographic symbols. OSGi support became a goal, etc.
>
>
> Le 17/02/13 00:45, Mattmann, Chris A (388J) a écrit :
>> Guys: another thing to note. Fast Feather tracks just opened up at
>> ApacheCon NA 2013. It's an opportunity for a short, but meaningful talk:
>>
>> http://s.apache.org/BqE
>>
>> Maybe we should do a Fast Feather on SIS? Any interest?
>
> Do we have someone who can be present?
>
> Martin
>
Re: NOAA Meetup
Posted by Adam Estrada <es...@gmail.com>.
Wanna create a directory in SVN for "presentations"? I don't see any issues with that assuming it does not violate any ASF rules and regs regarding the use of SVN for non-source code items.
Adam
On Feb 17, 2013, at 9:08 AM, Martin Desruisseaux wrote:
> Hello Chris, Adam and all
>
> Le 15/02/13 17:44, Mattmann, Chris A (388J) a écrit :
>> Guys, I need to prepare a short talk on Apache SIS for this NOAA meetup next week.
>>
>> I'm going to do it over Skype. Would love any input on slides or material you'd like me to include.
>
> I can send you by email some LibreOffice/OpenOffice.org slides that I have. Or maybe there is some space that we can use somewhere for this kind of material? Those slides would surely need to be adapted however.
>
>
> Le 16/02/13 21:42, Adam Estrada a écrit :
>> I think that it is important to note that what is currently being worked on not only helps to promote interoperability, its helping to define it by adhering so rigorously to ISO and OGC standards. Your's and Martin's involvement with the OGC GeoAPI working group is huge for the geospatial community because you can help to promote the use of these standards across all communities. I really believe that the key takeaway should resemble something like this.
>
> I also believe that our efforts in participating to standards are a very important aspect. GeoAPI is one aspect, but hopefully would not be the only one (after all, we still don't know if GeoAPI will succeed). I think that participation to the meteo-oceanography group is also important and seems close to the concern of many SIS members. Actually, I would love to present SIS as a library having a focus on science :-). One real use case that I have see is crossing data from physicians with data from oceanographers, for a study of cholera propagation. Because physicians and oceanographers are two quite different communities, crossing those data without standards is uneasy. The standards required here are more complex than the usual WMS (we need quality and uncertainties estimations, etc.).
>
> An other aspect that we could said is that SIS benefits from the experience gained from the previous projects: we have learn what worked and what have been bad idea. Every class that we port to SIS is an opportunity to revisit it and sometime to simplify it. When a feature seems overly complex, we have the possibility to search in the previous projects how this feature was used. This help us to determine how it can be simplified.
>
> An other reason for revisiting classes one-by-one is that the Java landscape as changed: JavaFX and Android need to be keep in mind, which imply for example to try to isolate Java2D dependencies in dedicated classes. Some factories may be replaced by JSR-330 (dependency injection). Support for supplementary Unicode characters become worthy, since they now include geographic symbols. OSGi support became a goal, etc.
>
>
> Le 17/02/13 00:45, Mattmann, Chris A (388J) a écrit :
>> Guys: another thing to note. Fast Feather tracks just opened up at
>> ApacheCon NA 2013. It's an opportunity for a short, but meaningful talk:
>>
>> http://s.apache.org/BqE
>>
>> Maybe we should do a Fast Feather on SIS? Any interest?
>
> Do we have someone who can be present?
>
> Martin
>
Re: NOAA Meetup
Posted by Adam Estrada <es...@gmail.com>.
I just added some slides as well...
A
On Feb 17, 2013, at 3:51 PM, Martin Desruisseaux wrote:
> Hello Chris
>
> Le 17/02/13 17:59, Mattmann, Chris A (388J) a écrit :
>> I've created:
>>
>> http://svn.apache.org/repos/asf/sis/presentations/NOAA-Meetup-Feb21-2013
>
> I have committed a "SIS.fodp" document. This was created with LibreOffice 4.0. The "fodp" format is the LibreOffice/OpenOffice.org flat XML, using clear text instead of binary file. The hope is to allow Subversion to do better diff job when committing revisions. Please feel free to overwrite this "SIS.fodp" file with any change, including removal of any irrelevant material. I don't think that there is any reason to keep "SIS.fodp" in its current state (no need to create copy before modification in my opinion).
>
>
>> I will be giving a bunch of other presentations and am also a known face
>> around Apache and it would be nice for someone else, e.g., you Martin or
>> Adam to do it, but the timeline may be too short to pull that off.
>
> Since I already travelled for the OGC meeting, I need to settle down a little bit in order to make more progress in the work... Sometime, we have the chance to make a single travel for two meetings (e.g. OGC followed for FOSS4G in the same area). This kind of opportunity (Apache SIS meeting close to an OGC or FOSS4G meeting) would be ideal... We will see.
>
> Thanks for all your comments :-)
>
> Martin
>
Re: NOAA Meetup
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Thanks to Martin and Adam for providing this content. Totally understand
about the travel, Martin, maybe we can do something for SIS at the next
ApacheCon EU or whenever the next meeting is.
Thanks!
Cheers,
Chris
On 2/17/13 12:51 PM, "Martin Desruisseaux"
<ma...@geomatys.fr> wrote:
>Hello Chris
>
>Le 17/02/13 17:59, Mattmann, Chris A (388J) a écrit :
>> I've created:
>>
>> http://svn.apache.org/repos/asf/sis/presentations/NOAA-Meetup-Feb21-2013
>
>I have committed a "SIS.fodp" document. This was created with
>LibreOffice 4.0. The "fodp" format is the LibreOffice/OpenOffice.org
>flat XML, using clear text instead of binary file. The hope is to allow
>Subversion to do better diff job when committing revisions. Please feel
>free to overwrite this "SIS.fodp" file with any change, including
>removal of any irrelevant material. I don't think that there is any
>reason to keep "SIS.fodp" in its current state (no need to create copy
>before modification in my opinion).
>
>
>> I will be giving a bunch of other presentations and am also a known face
>> around Apache and it would be nice for someone else, e.g., you Martin or
>> Adam to do it, but the timeline may be too short to pull that off.
>
>Since I already travelled for the OGC meeting, I need to settle down a
>little bit in order to make more progress in the work... Sometime, we
>have the chance to make a single travel for two meetings (e.g. OGC
>followed for FOSS4G in the same area). This kind of opportunity (Apache
>SIS meeting close to an OGC or FOSS4G meeting) would be ideal... We will
>see.
>
>Thanks for all your comments :-)
>
> Martin
>
Re: NOAA Meetup
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Chris
Le 17/02/13 17:59, Mattmann, Chris A (388J) a écrit :
> I've created:
>
> http://svn.apache.org/repos/asf/sis/presentations/NOAA-Meetup-Feb21-2013
I have committed a "SIS.fodp" document. This was created with
LibreOffice 4.0. The "fodp" format is the LibreOffice/OpenOffice.org
flat XML, using clear text instead of binary file. The hope is to allow
Subversion to do better diff job when committing revisions. Please feel
free to overwrite this "SIS.fodp" file with any change, including
removal of any irrelevant material. I don't think that there is any
reason to keep "SIS.fodp" in its current state (no need to create copy
before modification in my opinion).
> I will be giving a bunch of other presentations and am also a known face
> around Apache and it would be nice for someone else, e.g., you Martin or
> Adam to do it, but the timeline may be too short to pull that off.
Since I already travelled for the OGC meeting, I need to settle down a
little bit in order to make more progress in the work... Sometime, we
have the chance to make a single travel for two meetings (e.g. OGC
followed for FOSS4G in the same area). This kind of opportunity (Apache
SIS meeting close to an OGC or FOSS4G meeting) would be ideal... We will
see.
Thanks for all your comments :-)
Martin
Re: NOAA Meetup
Posted by Adam Estrada <es...@gmail.com>.
I would love to be there but my travel budget is extremely limited this year :( I will post a couple of slides I have related to the OGC and interoperability.
A
On Feb 17, 2013, at 11:59 AM, Mattmann, Chris A (388J) wrote:
> Hey Martin,
>
> On 2/17/13 6:08 AM, "Martin Desruisseaux"
> <ma...@geomatys.fr> wrote:
>
>> Hello Chris, Adam and all
>>
>> Le 15/02/13 17:44, Mattmann, Chris A (388J) a écrit :
>>> Guys, I need to prepare a short talk on Apache SIS for this NOAA meetup
>>> next week.
>>>
>>> I'm going to do it over Skype. Would love any input on slides or
>>> material you'd like me to include.
>>
>> I can send you by email some LibreOffice/OpenOffice.org slides that I
>> have. Or maybe there is some space that we can use somewhere for this
>> kind of material? Those slides would surely need to be adapted however.
>
> That would be great!
>
> I've created:
>
> http://svn.apache.org/repos/asf/sis/presentations/NOAA-Meetup-Feb21-2013
>
> For this!
>
>>
>>
>> Le 16/02/13 21:42, Adam Estrada a écrit :
>>> I think that it is important to note that what is currently being
>>> worked on not only helps to promote interoperability, its helping to
>>> define it by adhering so rigorously to ISO and OGC standards. Your's and
>>> Martin's involvement with the OGC GeoAPI working group is huge for the
>>> geospatial community because you can help to promote the use of these
>>> standards across all communities. I really believe that the key takeaway
>>> should resemble something like this.
>>
>> I also believe that our efforts in participating to standards are a very
>> important aspect. GeoAPI is one aspect, but hopefully would not be the
>> only one (after all, we still don't know if GeoAPI will succeed).
>
> Of course it will succeed, I mean c'mon Martin, we're involved! And you're
> leading it. How would it not succeed? :)
>
>> I
>> think that participation to the meteo-oceanography group is also
>> important and seems close to the concern of many SIS members. Actually,
>> I would love to present SIS as a library having a focus on science :-).
>
> ++50 to focusing on science.
>
>>
>> One real use case that I have see is crossing data from physicians with
>> data from oceanographers, for a study of cholera propagation. Because
>> physicians and oceanographers are two quite different communities,
>> crossing those data without standards is uneasy. The standards required
>> here are more complex than the usual WMS (we need quality and
>> uncertainties estimations, etc.).
>
> +1
>
>>
>> An other aspect that we could said is that SIS benefits from the
>> experience gained from the previous projects: we have learn what worked
>> and what have been bad idea. Every class that we port to SIS is an
>> opportunity to revisit it and sometime to simplify it. When a feature
>> seems overly complex, we have the possibility to search in the previous
>> projects how this feature was used. This help us to determine how it can
>> be simplified.
>
> +1 and also the opportunity to look here at Apache to see if there is
> cross fertilization with other Apache software to implement it too,
> getting those guys vested and interested in what we are doing.
>
>>
>> An other reason for revisiting classes one-by-one is that the Java
>> landscape as changed: JavaFX and Android need to be keep in mind, which
>> imply for example to try to isolate Java2D dependencies in dedicated
>> classes. Some factories may be replaced by JSR-330 (dependency
>> injection). Support for supplementary Unicode characters become worthy,
>> since they now include geographic symbols. OSGi support became a goal,
>> etc.
>
> +1
>
>>
>>
>> Le 17/02/13 00:45, Mattmann, Chris A (388J) a écrit :
>>> Guys: another thing to note. Fast Feather tracks just opened up at
>>> ApacheCon NA 2013. It's an opportunity for a short, but meaningful talk:
>>>
>>> http://s.apache.org/BqE
>>>
>>> Maybe we should do a Fast Feather on SIS? Any interest?
>>
>> Do we have someone who can be present?
>
> I will be there, as will Paul Ramirez , from the Apache SIS community.
> That said,
> I will be giving a bunch of other presentations and am also a known face
> around Apache and it would be nice for someone else, e.g., you Martin or
> Adam to do it, but the timeline may be too short to pull that off.
>
> Cheers,
> Chris
>
>>
>> Martin
>>
>
Re: NOAA Meetup
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Martin,
On 2/17/13 6:08 AM, "Martin Desruisseaux"
<ma...@geomatys.fr> wrote:
>Hello Chris, Adam and all
>
>Le 15/02/13 17:44, Mattmann, Chris A (388J) a écrit :
>> Guys, I need to prepare a short talk on Apache SIS for this NOAA meetup
>>next week.
>>
>> I'm going to do it over Skype. Would love any input on slides or
>>material you'd like me to include.
>
>I can send you by email some LibreOffice/OpenOffice.org slides that I
>have. Or maybe there is some space that we can use somewhere for this
>kind of material? Those slides would surely need to be adapted however.
That would be great!
I've created:
http://svn.apache.org/repos/asf/sis/presentations/NOAA-Meetup-Feb21-2013
For this!
>
>
>Le 16/02/13 21:42, Adam Estrada a écrit :
>> I think that it is important to note that what is currently being
>>worked on not only helps to promote interoperability, its helping to
>>define it by adhering so rigorously to ISO and OGC standards. Your's and
>>Martin's involvement with the OGC GeoAPI working group is huge for the
>>geospatial community because you can help to promote the use of these
>>standards across all communities. I really believe that the key takeaway
>>should resemble something like this.
>
>I also believe that our efforts in participating to standards are a very
>important aspect. GeoAPI is one aspect, but hopefully would not be the
>only one (after all, we still don't know if GeoAPI will succeed).
Of course it will succeed, I mean c'mon Martin, we're involved! And you're
leading it. How would it not succeed? :)
> I
>think that participation to the meteo-oceanography group is also
>important and seems close to the concern of many SIS members. Actually,
>I would love to present SIS as a library having a focus on science :-).
++50 to focusing on science.
>
>One real use case that I have see is crossing data from physicians with
>data from oceanographers, for a study of cholera propagation. Because
>physicians and oceanographers are two quite different communities,
>crossing those data without standards is uneasy. The standards required
>here are more complex than the usual WMS (we need quality and
>uncertainties estimations, etc.).
+1
>
>An other aspect that we could said is that SIS benefits from the
>experience gained from the previous projects: we have learn what worked
>and what have been bad idea. Every class that we port to SIS is an
>opportunity to revisit it and sometime to simplify it. When a feature
>seems overly complex, we have the possibility to search in the previous
>projects how this feature was used. This help us to determine how it can
>be simplified.
+1 and also the opportunity to look here at Apache to see if there is
cross fertilization with other Apache software to implement it too,
getting those guys vested and interested in what we are doing.
>
>An other reason for revisiting classes one-by-one is that the Java
>landscape as changed: JavaFX and Android need to be keep in mind, which
>imply for example to try to isolate Java2D dependencies in dedicated
>classes. Some factories may be replaced by JSR-330 (dependency
>injection). Support for supplementary Unicode characters become worthy,
>since they now include geographic symbols. OSGi support became a goal,
>etc.
+1
>
>
>Le 17/02/13 00:45, Mattmann, Chris A (388J) a écrit :
>> Guys: another thing to note. Fast Feather tracks just opened up at
>> ApacheCon NA 2013. It's an opportunity for a short, but meaningful talk:
>>
>> http://s.apache.org/BqE
>>
>> Maybe we should do a Fast Feather on SIS? Any interest?
>
>Do we have someone who can be present?
I will be there, as will Paul Ramirez , from the Apache SIS community.
That said,
I will be giving a bunch of other presentations and am also a known face
around Apache and it would be nice for someone else, e.g., you Martin or
Adam to do it, but the timeline may be too short to pull that off.
Cheers,
Chris
>
> Martin
>
Re: FW: NOAA Meetup
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Chris, Adam and all
Le 15/02/13 17:44, Mattmann, Chris A (388J) a écrit :
> Guys, I need to prepare a short talk on Apache SIS for this NOAA meetup next week.
>
> I'm going to do it over Skype. Would love any input on slides or material you'd like me to include.
I can send you by email some LibreOffice/OpenOffice.org slides that I
have. Or maybe there is some space that we can use somewhere for this
kind of material? Those slides would surely need to be adapted however.
Le 16/02/13 21:42, Adam Estrada a écrit :
> I think that it is important to note that what is currently being worked on not only helps to promote interoperability, its helping to define it by adhering so rigorously to ISO and OGC standards. Your's and Martin's involvement with the OGC GeoAPI working group is huge for the geospatial community because you can help to promote the use of these standards across all communities. I really believe that the key takeaway should resemble something like this.
I also believe that our efforts in participating to standards are a very
important aspect. GeoAPI is one aspect, but hopefully would not be the
only one (after all, we still don't know if GeoAPI will succeed). I
think that participation to the meteo-oceanography group is also
important and seems close to the concern of many SIS members. Actually,
I would love to present SIS as a library having a focus on science :-).
One real use case that I have see is crossing data from physicians with
data from oceanographers, for a study of cholera propagation. Because
physicians and oceanographers are two quite different communities,
crossing those data without standards is uneasy. The standards required
here are more complex than the usual WMS (we need quality and
uncertainties estimations, etc.).
An other aspect that we could said is that SIS benefits from the
experience gained from the previous projects: we have learn what worked
and what have been bad idea. Every class that we port to SIS is an
opportunity to revisit it and sometime to simplify it. When a feature
seems overly complex, we have the possibility to search in the previous
projects how this feature was used. This help us to determine how it can
be simplified.
An other reason for revisiting classes one-by-one is that the Java
landscape as changed: JavaFX and Android need to be keep in mind, which
imply for example to try to isolate Java2D dependencies in dedicated
classes. Some factories may be replaced by JSR-330 (dependency
injection). Support for supplementary Unicode characters become worthy,
since they now include geographic symbols. OSGi support became a goal, etc.
Le 17/02/13 00:45, Mattmann, Chris A (388J) a écrit :
> Guys: another thing to note. Fast Feather tracks just opened up at
> ApacheCon NA 2013. It's an opportunity for a short, but meaningful talk:
>
> http://s.apache.org/BqE
>
> Maybe we should do a Fast Feather on SIS? Any interest?
Do we have someone who can be present?
Martin