Re: [Geotools-devel] Problem with General Oblique transform latitude?

2016-04-04 Thread Ben Caradoc-Davies 
On 05/04/16 08:27, Maciej Filocha wrote:
> W dniu 02.04.2016 o 02:34, Ben Caradoc-Davies pisze:
>> I have created a Jira issue for this problem:
>> [GEOT-5396] Incorrect General Oblique transform
>> https://osgeo-org.atlassian.net/browse/GEOT-5396
> I'll prepare fix for it this week.

Thanks very much. The projection seems to work fine for me if I set 
latitude_of_origin to 90 degrees minus the correct latitude_of_origin, 
so I have workaround. For example, for a grid with origin at latitude 54 
degrees North, I am using PARAMETER["latitude_of_origin",36] (36=90-54). 
I do not know if this is correct, but the results are plausible.

>> One other question: is General_Oblique the most appropriate name for
>> this MapProjection? Although the implementation methods could be used be
>> used to build general oblique projections, its Provider does not support
>> other parameters. Could this projection instead be called Rotated_Pole
>> or Rotated_Latitude_Longitude?
> It was my initial idea to use one of that two names. Later on, I decided
> to follow proj4 internal name of "ob_tran":
> echo "0 0" | cs2cs -v +proj=ob_tran +o_proj=longlat +to_meter=0.0174533
> +lon_0=106 +o_lat_p=36 +ellps=WGS84 +datum=WGS84 +wktext +nodefs
> I agree, this could be misleading. It's up to you, core developers, to
> judge it!

I am not an expert on projections, so I am hoping others on this list 
can suggest a preferred alternative. I can find no OGC equivalent. I 
suspect that, as a projection, this may be considered an Oblique Plate 
Carree, but I have never seen it referred to as such and so choosing 
this name would be unhelpful.

The NetCDF CF Conventions use the term "rotated pole":
http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/build/ch05s06.html

The COSMO manual uses the terms "rotated spherical" and "rotated 
geographic". GRIB2 GDS documentation uses "rotated latitude/longitude":
http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_table3-1.shtml

Maciej, your first guess was "rotated pole":
http://osgeo-org.1560.x6.nabble.com/Rotated-pole-coordinate-system-td5204800.html

I would be happy with "rotated pole", but I lack expertise in this area.

One other question is whether this renaming is considered an API change. 
According to Jira, this projection has been included in all 14.x 
(stable) releases to changing the name will break code that uses it.

Kind regards,

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Reminder: GeoTools / GeoServer Meeting at 19:30 UTC on Tuesday

2016-04-04 Thread Ben Caradoc-Davies 
GeoTools / GeoServer committee meeting on Skype at 19:30 UTC on Tuesday:
http://www.timeanddate.com/worldclock/fixedtime.html?msg=GeoTools+%2F+GeoServer+Meeting=2016=4=5=19=30=0=1

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] proposal: refactor vector mask external footprint generation

2016-04-04 Thread Jody Garnett 
Here is the proposal from Daniele Romagnoli:
-
https://github.com/geotools/geotools/wiki/Refactor-vector-mask-external-footprint-generation

Thanks for pulling this together Daniele (the proposal is quite detailed
and has code examples making it easy to review).

PMC members please respond as appropriate, we welcome community support
from any one else on the list with enthusiasm for this "new" feature.
--
Jody Garnett
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Problem with General Oblique transform latitude?

2016-04-04 Thread Maciej Filocha 
Ben,

W dniu 02.04.2016 o 02:34, Ben Caradoc-Davies pisze:
> I have created a Jira issue for this problem:
>
> [GEOT-5396] Incorrect General Oblique transform
> https://osgeo-org.atlassian.net/browse/GEOT-5396

I'll prepare fix for it this week.

>
> One other question: is General_Oblique the most appropriate name for
> this MapProjection? Although the implementation methods could be used be
> used to build general oblique projections, its Provider does not support
> other parameters. Could this projection instead be called Rotated_Pole
> or Rotated_Latitude_Longitude?

It was my initial idea to use one of that two names. Later on, I decided 
to follow proj4 internal name of "ob_tran":

echo "0 0" | cs2cs -v +proj=ob_tran +o_proj=longlat +to_meter=0.0174533 
+lon_0=106 +o_lat_p=36 +ellps=WGS84 +datum=WGS84 +wktext +nodefs

I agree, this could be misleading. It's up to you, core developers, to 
judge it!


Regards

Maciej

--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Adding external vector mask (footprint) support to GDAL plugin

2016-04-04 Thread Jody Garnett 
Looks good, let's call for PMC review (ie send an email and get this
reviewed/approved).

--
Jody Garnett

On 4 April 2016 at 01:58, Daniele Romagnoli <
daniele.romagn...@geo-solutions.it> wrote:

> Hi Jody,
> I have updated the pull request as well as the proposal:
>
> https://github.com/geotools/geotools/wiki/Refactor-vector-mask-external-footprint-generation
>
> Basically, as per your suggestion, I have listed the main
> classes/interfaces moved/extracted from gt-imagemosaic to gt-coverage with
> a reference to the online javadoc.
> Then, I have summarized the interfaces.
>
> Please, let me know if that looks good or if I should add some more.
>
> Best Regards,
> Daniele
>
>
>
> On Fri, Apr 1, 2016 at 7:43 PM, Jody Garnett 
> wrote:
>
>> Hi Jody,
>>
>>> thanks for having setup a starting point.
>>> I have question since I think it's the first time that a set of classes
>>> is moved from a plugin module to a core one.
>>>
>>> Is there any convention/guidelines to follow up when setting up a
>>> proposal for this kind of "move-classes refactoring"? (see next question)
>>>
>>
>> It is just a normal proposal - we are making a chance that affects other
>> developers and want to ask around first, check the release schedule, make
>> sure you have enough resources to do the work, or give you an opportunity
>> to ask for help.
>>
>>
>>> In terms of coding, I have mainly moved couple of interfaces, related
>>> implementing classes and auxiliary helper classes and enums from gt-mosaic
>>> and gt-coverage.
>>> What should I add in the "API change" part of the proposal?
>>>
>>
>> Suggestions:
>> - You could list the classes and provide links to their existing javadocs
>> online
>> - You could provide an outline of the classes since they are showing up
>> as new public api and their may be questions
>>
>>
>>> Should I simply add the "interfaces" (the API) in gt-coverage and avoid
>>> listing every single class/variant implementing them, enums, utilities?
>>>
>>
>> Yes, we are more concerned with showing the functionality change so
>> project management committee members can approve the work. The proposal is
>> about communication, the actual details we trust you to do as a committer /
>> maintainer.
>>
>>
>>> I also think that I shouldn't add before-after section for
>>> gt-imagemosaic being a plugin, right?
>>>
>>
>> Correct.
>>
>> Please, let me know.
>>>
>>
>> Thanks for the email discussion, we can revise the proposal based on
>> feedback.
>>
>> As someone who watches the docs I want to make sure there is a task to
>> add a code example to the docs. Reminds me to pester Ian for raster
>> symbolizer normalization docs ...
>>
>
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Daniele Romagnoli
> Senior Software Engineer
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax:  +39 0584 1660272
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
>
--

Re: [Geotools-devel] [JIRA] (GEOT-5388) Let TemporalConverterFactory provide for conversion from Long to Date

2016-04-04 Thread Mark Prins 
I've created PR's for master [1] and 14.x [2], I can create a 13.x PR as
well if required.
Not sure if this qualifies as a new feature or a fix, but it fixes the
parsing of ArcGIS REST JSON responses where dates of features are written
out as epoch stamps

[1] https://github.com/geotools/geotools/pull/1146
[2] https://github.com/geotools/geotools/pull/1147


Mark

2016-03-25 18:17 GMT+01:00 Mark Prins (JIRA) :

> Mark Prins
> 
> *created* an issue
>
> GeoTools  / [image:
> Improvement]  GEOT-5388
> 
> Let TemporalConverterFactory provide for conversion from Long to Date
> 
> Issue Type: [image: Improvement] Improvement
> Affects Versions: 15-beta, 14.3
> Assignee: Unassigned
> Components: main
> Created: 25/Mar/16 6:16 PM
> Priority: [image: Medium] Medium
> Reporter: Mark Prins
> 
>
> Currently org.geotools.util.TemporalConverterFactory fails to convert from
> Long to Date, this is an issue while converting features from ArcGIS server
> REST/json responses that have a date as the esriFieldTypeDate is
> communicated as a long value representing epoch milliseconds since 1-1-1970
> in GMT
> [image: Add Comment]
>  Add Comment
> 
>
> This message was sent by Atlassian JIRA (v7.2.0-OD-04-029#72002-
> sha1:f50e4de)
> [image: Atlassian logo]
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Improper Caching in ColorModelFactory

2016-04-04 Thread sikeoka 
The Travis build for the pull request ran successfully after re-running it.

Steve Ikeoka



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Improper-Caching-in-ColorModelFactory-tp5258720p5259551.html
Sent from the geotools-devel mailing list archive at Nabble.com.

--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] gt-coverage refactorings

2016-04-04 Thread Niels Charlier 

Hi Simone, Daniele, List,

Here is what we currently have for our proposal:

https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-for-extensibility. 



This is still is discussion phase, we'd like to hear your input :)

Kind Regards
Niels

On 31-03-16 20:14, Niels Charlier wrote:
I have looked at Daniele's PR (superficially) and it looks good, but I 
would expect a proposal is in order to move a lot of API from a plugin 
to a core module.


As far as I can see, there is little or no overlap between the two 
bodies of work at the moment. I don't expect any issues there.


Considering our proposal - will be posting this soonish - we can never 
move everything that demstore depends on from imagemosaic to the 
coverage module, it's nearly everything. I much prefer the idea of 
creating a more public API for imagemosaic itself and documenting this 
(perhaps promoting it to a core module?).


Kind Regards
Niels

On 31-03-16 19:53, Jody Garnett wrote:
Catching up with the geotools codebase for a bit ... and I also owe 
Andrea an update from the gt-dem community module progress.


I see we have two teams looking at refactoring functionality into 
gt-coverage:


Daniele: Your pull request #1131 Supporting vector footprints on GDAL 
plugin  is moving 
some functionality from gt-mosaic to gt-coverage around generating 
footprints using GDAL and minor changes to CatalogManager.  I would 
like some feedback on how this affects the code-base stability (with 
respect to upcoming release); and we could help pull together a 
change proposal.


Devon & Niels: Although we have a community module, most of the work 
has taken place on a branch (to hack hooks into gt-image-mosaic 
classes such as CatalogManger). The next step is to regroup and 
produce a change proposal. I assume this change proposal would move 
some functionality from gt-moasic to gt-coverage (or depend on 
gt-mosaic which would involve some clean up and documentation of the 
internals as public api).


The other update is a change in scope - the multi-resolution dem is 
no longer just a dem. It now has to cover both dem and imagery. The 
critical difference between this and gt-moasic ends up being setting 
up a processing chain (renderable graph) for each granule allowing 
content from different projections to be merged (with an appropriate 
speed penalty). I am not sure if the different granules have to be 
coerced into the same band structure or not (something that is more 
challenging for a DEM which may be measured in meters or feet).

--
Jody Garnett


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140


___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel




--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140


___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Adding external vector mask (footprint) support to GDAL plugin

2016-04-04 Thread Daniele Romagnoli 
Hi Jody,
I have updated the pull request as well as the proposal:
https://github.com/geotools/geotools/wiki/Refactor-vector-mask-external-footprint-generation

Basically, as per your suggestion, I have listed the main
classes/interfaces moved/extracted from gt-imagemosaic to gt-coverage with
a reference to the online javadoc.
Then, I have summarized the interfaces.

Please, let me know if that looks good or if I should add some more.

Best Regards,
Daniele



On Fri, Apr 1, 2016 at 7:43 PM, Jody Garnett  wrote:

> Hi Jody,
>
>> thanks for having setup a starting point.
>> I have question since I think it's the first time that a set of classes
>> is moved from a plugin module to a core one.
>>
>> Is there any convention/guidelines to follow up when setting up a
>> proposal for this kind of "move-classes refactoring"? (see next question)
>>
>
> It is just a normal proposal - we are making a chance that affects other
> developers and want to ask around first, check the release schedule, make
> sure you have enough resources to do the work, or give you an opportunity
> to ask for help.
>
>
>> In terms of coding, I have mainly moved couple of interfaces, related
>> implementing classes and auxiliary helper classes and enums from gt-mosaic
>> and gt-coverage.
>> What should I add in the "API change" part of the proposal?
>>
>
> Suggestions:
> - You could list the classes and provide links to their existing javadocs
> online
> - You could provide an outline of the classes since they are showing up as
> new public api and their may be questions
>
>
>> Should I simply add the "interfaces" (the API) in gt-coverage and avoid
>> listing every single class/variant implementing them, enums, utilities?
>>
>
> Yes, we are more concerned with showing the functionality change so
> project management committee members can approve the work. The proposal is
> about communication, the actual details we trust you to do as a committer /
> maintainer.
>
>
>> I also think that I shouldn't add before-after section for gt-imagemosaic
>> being a plugin, right?
>>
>
> Correct.
>
> Please, let me know.
>>
>
> Thanks for the email discussion, we can revise the proposal based on
> feedback.
>
> As someone who watches the docs I want to make sure there is a task to add
> a code example to the docs. Reminds me to pester Ian for raster symbolizer
> normalization docs ...
>



-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:  +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel