{"action":"created","issue":{"url":"https://api.github.com/repos/ISO-TC211/ISO19111/issues/36","repository_url":"https://api.github.com/repos/ISO-TC211/ISO19111","labels_url":"https://api.github.com/repos/ISO-TC211/ISO19111/issues/36/labels{/name}","comments_url":"https://api.github.com/repos/ISO-TC211/ISO19111/issues/36/comments","events_url":"https://api.github.com/repos/ISO-TC211/ISO19111/issues/36/events","html_url":"https://github.com/ISO-TC211/ISO19111/issues/36","id":277795796,"number":36,"title":"TemporalQuantity","user":{"login":"marqh","id":1557321,"avatar_url":"https://avatars3.githubusercontent.com/u/1557321?v=4","gravatar_id":"","url":"https://api.github.com/users/marqh","html_url":"https://github.com/marqh","followers_url":"https://api.github.com/users/marqh/followers","following_url":"https://api.github.com/users/marqh/following{/other_user}","gists_url":"https://api.github.com/users/marqh/gists{/gist_id}","starred_url":"https://api.github.com/users/marqh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/marqh/subscriptions","organizations_url":"https://api.github.com/users/marqh/orgs","repos_url":"https://api.github.com/users/marqh/repos","events_url":"https://api.github.com/users/marqh/events{/privacy}","received_events_url":"https://api.github.com/users/marqh/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":25,"created_at":"2017-11-29T15:26:21Z","updated_at":"2017-12-06T11:47:19Z","closed_at":null,"author_association":"NONE","body":"The handling of temporal quantities linked to calendars could be taken out of CoordinateSystemAxis and provided only for TemporalCS entities.\r\n\r\nAs long as it were possible to have `axisUnit` able to be null in these cases, this would allow temporal special cases linked to calendars to be handled separately from unitOfMeasure specifications.\r\n\r\nThis approach could simplify axisUnit, providing functionality in a very similar way to ISO19111:2007, apart from in the new temporal case.\r\n\r\nAn adapted (and abridged) Coordinate Systems Package UML Diagram for this could be:\r\n\r\n![coordsyspkg](https://user-images.githubusercontent.com/1557321/33382557-fc3ad382-d518-11e7-9ac0-e1ff3ba89f89.png)\r\n\r\n\r\n\r\nPreceding discussions on an alternative proposal for AxisUnit simplification: #34 "},"comment":{"url":"https://api.github.com/repos/ISO-TC211/ISO19111/issues/comments/349616167","html_url":"https://github.com/ISO-TC211/ISO19111/issues/36#issuecomment-349616167","issue_url":"https://api.github.com/repos/ISO-TC211/ISO19111/issues/36","id":349616167,"user":{"login":"pebau","id":6102670,"avatar_url":"https://avatars1.githubusercontent.com/u/6102670?v=4","gravatar_id":"","url":"https://api.github.com/users/pebau","html_url":"https://github.com/pebau","followers_url":"https://api.github.com/users/pebau/followers","following_url":"https://api.github.com/users/pebau/following{/other_user}","gists_url":"https://api.github.com/users/pebau/gists{/gist_id}","starred_url":"https://api.github.com/users/pebau/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pebau/subscriptions","organizations_url":"https://api.github.com/users/pebau/orgs","repos_url":"https://api.github.com/users/pebau/repos","events_url":"https://api.github.com/users/pebau/events{/privacy}","received_events_url":"https://api.github.com/users/pebau/received_events","type":"User","site_admin":false},"created_at":"2017-12-06T11:47:19Z","updated_at":"2017-12-06T11:47:19Z","author_association":"NONE","body":"Hi all,\n\nagain my 2 cents from someone deailing with space/time coordinates all the time\n;-) in practice.\n\n\nOn 12/06/2017 12:58 AM, Martin Desruisseaux wrote:\n>\n> I think the new language for 19111 §10.3 is an improvement. But would the\n> following amendments be acceptable?\n>\n>     |dateTime| strings in the proleptic Gregorian calendar as described in ISO\n>     8601.\n>\n> |dateTime| is a type of its own, distinct from its |CharacterSequence|\n> representation. It can make a difference when ordering values:\n> 2017-01-01T00:00Z may be interpreted as a date-time before\n> 2017-01-01T00:00:12Z. But when comparing their string representations, we get\n> the opposite order because \"Z\" is after \":\" in ASCII table.\n>\n\nabsolutely supported - \"string\" is not the adequate type, 8601 syntax follows\nown rules.\n\n> On the next two items — /\"a temporal coordinate system using *integer count*\n> which can be *unambiguously* converted to a |dateTime|\"/ and /\"a temporal\n> coordinate system that has a continuous axis expressed as a *real number* ,\n> which can only be *ambiguously* converted to a |dateTime|\"/ — it seems to me\n> that the fact of using integers or real numbers is independent of the fact\n> that a conversion is ambiguous or not. We may be counting seconds since\n> January 1st 1970, in which case we are subject to the same ambiguity regarding\n> leap seconds than if we were using real numbers. Or maybe you intended to\n> restrict the integer case to days or longer units? If yes, then what about the\n> following?\n>\n>     a temporal coordinate system using integer count of days or longer\n>     temporal units, which can be unambiguously converted to a |dateTime| in\n>     the ISO 8601 proleptic Gregorian calendar as an offset from the datum time\n>     origin, another |dateTime| ISO 8601 string.\n>\n\nI continue to be bewildered by having int and real distinction for the same\nthing - it will be very hard to motivate to the communities to have such a\ncounterintuitive, overcomplicating definition.\n\n> I omitted \"ISO 8601\" because in my understanding, that standard does not\n> define the Gregorian calendar; it only defines a characters representation,\n> which does not need to be applied to coordinate values here. The standard\n> summary <https://www.iso.org/standard/40874.html> said: /\"ISO 8601:2004 does\n> not assign any particular meaning or interpretation to any data element that\n> uses representations in accordance with ISO 8601:2004. Such meaning will be\n> determined by the context of the application.\"/\n>\n\nthis is in line with one of the outcomes of the OGC Temporal.DWG: 8601 defines\nsyntax, but not semantics. Calendars have not been addressed yet, therefore\neverybody silently assumes it is Gregorian-Proleptic. This will change in future.\n\n>     a temporal coordinate system that has a continuous axis expressed as real\n>     numbers, which can only may be ambiguously converted to a dateTime in the\n>     ISO 8601 proleptic Gregorian calendar as an offset from the datum time\n>     origin, another |dateTime| ISO 8601 string. Results may differ based on\n>     implementation.\n>\n> I replaced \"can only\" by \"may\" because some languages define precisely their\n> rules for converting such numbers to dates, including their behavior regarding\n> leap seconds. One example is the UTC with Smoothed Leap Seconds (UTC-SLS)\n> <http://www.cl.cam.ac.uk/%7Emgk25/time/utc-sls/> approach, adopted by the Java\n> language since 2014.\n>\n>     I think it is important that any definition of a temporalQuantity may be\n>     defined independently, without any nameStandardUnit, scale, offset etc.\n>\n> I wonder which data we are talking about? I do not remember having seen\n> calendar quantity in time series except for climatology data (e.g. average\n> January temperature of no particular year). Could you provide us an example of\n> time series using calendar quantities?\n>\n>     I do not have a use case to support defining any temporalQuantity except\n>     seconds as a unitOfMeasure related to SI.\n>\n> Isn't the opposite situation, many time series using elapsed time in minutes,\n> hours, days or other temporal units since an epoch? For example in netCDF\n> files, the |units| attribute of time axis is something like \"hours since\n> 1980-01-01T00:00Z\". In WMO GRIB2 files, a single reference time is given as a\n> (year, month, day, /etc./) tuple for the whole file, then from that point the\n> time of every data slice is given using a single temporal units since that\n> reference time. In above paragraph, does \"use case\" means something else than\n> supporting netCDF, GRIB2 and other file formats?\n>\n>     I would not define a TCRS TCS with an axisUnit of hour defined with\n>     respect to seconds. If I received one of these, I would not know whether\n>     to ignore this definition and include a leap second or take the definition\n>     at face value and ignore potential leap seconds.\n>\n> But then, how are we supposed to read netCDF, GRIB2 and other files? I think\n> that the common practice is to ignore leap seconds for three reasons:\n>\n>   * The time series are usually not long enough for leap seconds to become\n>     significant. After some period (e.g. one year) we reach end of file. A new\n>     netCDF or GRIB file is then created for the next year, with a new\n>     reference date in ISO 8601 format.\n>   * If we nevertheless have very long time series, the /UTC with Smoothed Leap\n>     Seconds/ approach is one way to handle the problem at the cost of a\n>     maximal inaccuracy of one second compared to UTC clock.\n>   * It seems to me that using calendars would make very difficult to perform\n>     time series analysis like spectral analysis. The Fast Fourier Transform\n>     (FFT) algorithm that I have learn needs a constant step between each\n>     sample value.\n>\n> In summary, I think that the core point where we have different views is about\n> whether calendar arithmetic on time axis should be common or rare. I think\n> they may be common in other contexts, but rare on the time axis. If this is\n> the case, should we try to list some use cases?\n>\n> —\n> You are receiving this because you are subscribed to this thread.\n> Reply to this email directly, view it on GitHub\n> <https://github.com/ISO-TC211/ISO19111/issues/36#issuecomment-349482407>, or\n> mute the thread\n> <https://github.com/notifications/unsubscribe-auth/AF0ejv0TMBp5KPMc0bx0tlCiEwW__QcYks5s9diwgaJpZM4QvJHA>.\n>\n\n19111 is in danger of becoming a weird definition as far as time is concerned,\ndriven by traditional horizontal Earth surface concepts which do not transpose\ninto this new dimension. We need to accept that time has its own behavior that\ntranscends floats (such as non-trivial parsing and date arithmetics). Martin has\nmade excellent points here, and I do hope that he will get heard, for the sake\nof us users out there.\n\n-Peter\n\n\n\n\n-- \nDr. Peter Baumann\n - Executive Director, rasdaman GmbH Bremen (HRB 26793)\n   www.rasdaman.com, mail: baumann@rasdaman.com\n   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882\n - Professor of Computer Science, Jacobs University Bremen\n   www.faculty.jacobs-university.de/pbaumann\n   mail: p.baumann@jacobs-university.de\n   tel: +49-421-200-3178, fax: +49-421-200-493178\n\"A brilliant idea is a job halfdone.\"\n\n"}}
{"actor":{"display_login":"pebau"}}