Great, thanks for the input Jonathon and David. I think I have enough to
put together a proposal on how to improve the current patch. Going to start
that in a new thread.
On Tue, Apr 12, 2016 at 1:38 PM Jonathan Marino <mar...@mapstory.org> wrote:
> Just to be clear from the MapStory end, to be honest, we don't really care
> the time resolution on negative time - milli, seconds, hours. Just whatever
> is the most viable pathway to go back to geologic (circa 4.5 billion). We
> leave it to you to determine what you prefer.
>
> On Tue, Apr 12, 2016 at 2:57 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
>> Perfect, that is what I needed :)
>>
>> Ok, so having two types makes sense. One to be able to go back to time
>> zero but also limited in terms of resolution to seconds, and one that
>> doesn’t go all the way back but gives you down the millisecond.
>>
>> Or do you think that two types is overkill and we can get away with one
>> type interpreted as seconds?
>>
>> On Tue, Apr 12, 2016 at 12:51 PM David William Bitner <
>> bit...@dbspatial.com> wrote:
>>
>>> The Earth is 4.5 Billion Years old. Milliseconds takes us to ~290
>>> Million Years Ago, Seconds can get us to ~290 Billion Years Ago. Using
>>> seconds allows us to encompass the full geologic record but allows for less
>>> precision than storing milliseconds.
>>>
>>> On Tue, Apr 12, 2016 at 1:47 PM, Justin Deoliveira <jdeol...@gmail.com>
>>> wrote:
>>>
>>>> Thanks David. I was clear that native postgresql timestamp couldn’t do
>>>> the job, but my question was whether bigint had a big enough value space
>>>> for geologic time? If we interpret the value as milliseconds is it big
>>>> enough? Or do we need to interpret as seconds in order to go back far
>>>> enough?
>>>>
>>>> On Tue, Apr 12, 2016 at 12:00 PM David William Bitner <
>>>> bit...@dbspatial.com> wrote:
>>>>
>>>>> It's about the value space.
>>>>>
>>>>> Native PostgreSQL Timestamp can cover between 4713 BC to 294276 AD.
>>>>>
>>>>> BigInt can cover between ~ -9 and +9 Quintillion
>>>>>
>>>>> Which converting to seconds (9 Quintillion / (365*24*60*60)) is ~ 290
>>>>> Billion
>>>>>
>>>>> And to milliseconds (9 Quintillion / (365*24* 60*60*1000)) is ~ 290
>>>>> Million
>>>>>
>>>>> On Tue, Apr 12, 2016 at 11:48 AM, Justin Deoliveira <
>>>>> jdeol...@gmail.com> wrote:
>>>>>
>>>>>> Thanks for the info guys, You’ll have to bear with me as you walk me
>>>>>> through the nuances of representing time in this way.
>>>>>>
>>>>>> So in order to represent full geologic time do you need more than
>>>>>> just a numeric value? Or is that you just need a numeric type with a
>>>>>> bigger
>>>>>> value space?
>>>>>>
>>>>>> On Tue, Apr 12, 2016 at 10:31 AM David William Bitner <
>>>>>> bit...@dbspatial.com> wrote:
>>>>>>
>>>>>>> With the added rub that millis does not allow to go back quite far
>>>>>>> enough to deal with geologic time. If the same mechanism was used
>>>>>>> (Postgresql Domain), It could be possible to create something like
>>>>>>> "bigdate_milli" and "bigdate_sec" or "bigdate" and "reallybigdate".
>>>>>>>
>>>>>>> On Tue, Apr 12, 2016 at 11:28 AM, Justin Deoliveira <
>>>>>>> jdeol...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Thanks David, that helps a lot.
>>>>>>>>
>>>>>>>> So to summarize the ask is to be able to store dates as
>>>>>>>> milliseconds from the epoch, and have the geotools datastore map that
>>>>>>>> to a
>>>>>>>> java date type . With the current patch that logic is triggered is by
>>>>>>>> using
>>>>>>>> a domain type of “bigdate” in postgres. And because of the way type
>>>>>>>> mapping
>>>>>>>> works in the data store we need some subclass (called XDate in the
>>>>>>>> patch)
>>>>>>>> in order to map back to the database.
>>>>>>>>
>>>>>>>> Do I have it right?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Apr 12, 2016 at 8:18 AM David William Bitner <
>>>>>>>> bit...@dbspatial.com> wrote:
>>>>>>>>
>>>>>>>>> The rationale behind this is to be able to store dates beyond the
>>>>>>>>> PostgreSQL timestamp limit of 4713 BC to 294276 AD.
>>>>>>>>>
>>>>>>>>> Ian's patch allows for storage of the datetime as milliseconds
>>>>>>>>> from the Unix Epoch which gives roughly +/- 290 Million Years by
>>>>>>>>> storing as
>>>>>>>>> a bigint using a PostgreSQL Domain bigdate as a marker. ("CREATE
>>>>>>>>> DOMAIN
>>>>>>>>> bigdate bigint;" is all that means).
>>>>>>>>>
>>>>>>>>> The issue that MapStory/Geonode is running into currently is the
>>>>>>>>> requirement to be able to show the entire geologic record (the Earth
>>>>>>>>> is ~
>>>>>>>>> 4.2 Billion years old), so even this patch doesn't make it all the way
>>>>>>>>> there (although storing the datetime as seconds from the Unix Epoch
>>>>>>>>> would
>>>>>>>>> cover roughly +/-290 Billion which WOULD do the job).
>>>>>>>>>
>>>>>>>>> On Tue, Apr 12, 2016 at 7:30 AM, Justin Deoliveira <
>>>>>>>>> jdeol...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> This was my finding as well… couldn’t make up what was going on
>>>>>>>>>> here… which makes me think there is perhaps more to this patch on the
>>>>>>>>>> GeoNode side?
>>>>>>>>>>
>>>>>>>>>> Rather than flying blind has anyone tried to reach out to Ian
>>>>>>>>>> Schneider, who afaik is the original author of the patch? If not I
>>>>>>>>>> can give
>>>>>>>>>> that a shot and hopefully get him to weigh in.
>>>>>>>>>>
>>>>>>>>>> On Tue, Apr 12, 2016 at 1:30 AM Andrea Aime <
>>>>>>>>>> andrea.a...@geo-solutions.it> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Tue, Apr 12, 2016 at 8:59 AM, Jody Garnett <
>>>>>>>>>>> jody.garn...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Near as I can tell the point of this exercise is to provide a
>>>>>>>>>>>> mapping for bigdate:
>>>>>>>>>>>>
>>>>>>>>>>>> mappings.put("bigdate", XDate.class);
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Err yeah but I'm still lost, I can't see any such type in
>>>>>>>>>>> postgresql, nor
>>>>>>>>>>> I can find one searching the internet:
>>>>>>>>>>> http://www.postgresql.org/docs/9.3/static/datatype-datetime.html
>>>>>>>>>>>
>>>>>>>>>>> And yet it's used in the test table creations... but if I run it
>>>>>>>>>>> locally:
>>>>>>>>>>>
>>>>>>>>>>> > gttest=# CREATE TABLE "bigdates" (id integer PRIMARY KEY,d
>>>>>>>>>>> bigdate);
>>>>>>>>>>> ERROR: type "bigdate" does not exist
>>>>>>>>>>> LINE 1: CREATE TABLE "bigdates" (id integer PRIMARY KEY,d
>>>>>>>>>>> bigdate);
>>>>>>>>>>>
>>>>>>>>>>> So... I assume bigdate is some extended type in postgresql,
>>>>>>>>>>> installed as an
>>>>>>>>>>> extension? Yet I cannot find one providing this data type.
>>>>>>>>>>>
>>>>>>>>>>> I'm all for helping, would just like to know what it's for
>>>>>>>>>>> instead of getting in
>>>>>>>>>>> a strange patch at face value.... there might be a cleaner way
>>>>>>>>>>> to solve this,
>>>>>>>>>>> mocking with converters and centralized converters can cause
>>>>>>>>>>> side effects.
>>>>>>>>>>>
>>>>>>>>>>> Cheers
>>>>>>>>>>> Andrea
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> ==
>>>>>>>>>>> GeoServer Professional Services from the experts! Visit
>>>>>>>>>>> http://goo.gl/it488V for more information.
>>>>>>>>>>> ==
>>>>>>>>>>>
>>>>>>>>>>> Ing. Andrea Aime
>>>>>>>>>>> @geowolf
>>>>>>>>>>> Technical Lead
>>>>>>>>>>>
>>>>>>>>>>> GeoSolutions S.A.S.
>>>>>>>>>>> Via di Montramito 3/A
>>>>>>>>>>> 55054 Massarosa (LU)
>>>>>>>>>>> phone: +39 0584 962313
>>>>>>>>>>> fax: +39 0584 1660272
>>>>>>>>>>> mob: +39 339 8844549
>>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> -------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>> Find and fix application performance issues faster with
>>>>>>>>>>> Applications Manager
>>>>>>>>>>> Applications Manager provides deep performance insights into
>>>>>>>>>>> multiple tiers of
>>>>>>>>>>> your business applications. It resolves application problems
>>>>>>>>>>> quickly and
>>>>>>>>>>> reduces your MTTR. Get your free trial!
>>>>>>>>>>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> GeoTools-Devel mailing list
>>>>>>>>>>> GeoTools-Devel@lists.sourceforge.net
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> ************************************
>>>>>>>>> David William Bitner
>>>>>>>>> dbSpatial LLC
>>>>>>>>> 612-424-9932
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ************************************
>>>>>>> David William Bitner
>>>>>>> dbSpatial LLC
>>>>>>> 612-424-9932
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ************************************
>>>>> David William Bitner
>>>>> dbSpatial LLC
>>>>> 612-424-9932
>>>>>
>>>>
>>>
>>>
>>> --
>>> ************************************
>>> David William Bitner
>>> dbSpatial LLC
>>> 612-424-9932
>>>
>>
>
>
> --
> 815.222.9088
> @MapStory <http://twitter.com/mapstory>
>
>
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
