added temporal units to support binning by decade, hour, and minute#801
added temporal units to support binning by decade, hour, and minute#801rwgdrummer merged 1 commit intolocationtech:masterfrom
Conversation
|
To expose it to the commandline tools you have t o add it as options to the periodicity in SpatialTemporalDimensionalityTypeProvider. Also, if you could figure out a way to get "week" in there that would be awesome! |
| + TWO_DIGIT_NUMBER.format(value.get(Calendar.MONTH)) + "_" | ||
| + TWO_DIGIT_NUMBER.format(value.get(Calendar.DAY_OF_MONTH)) + "_" | ||
| + TWO_DIGIT_NUMBER.format(value.get(Calendar.HOUR_OF_DAY)) + "_" + TWO_DIGIT_NUMBER | ||
| .format(value.get(Calendar.MINUTE)))); |
There was a problem hiding this comment.
May be we should now consider compressing these a bit.
There was a problem hiding this comment.
perhaps a good idea - a req't for that compression is that for each periodicity/bin, the binary size must be fixed, but I don't think that should be a problem. preserving sort order actually shouldn't matter as we are just using the periodicity/bin as an enumeration...the more complex concern may be backwards compatibility?
There was a problem hiding this comment.
So what do we want to do here? I can come up with an approach to compress these a bit, which will require me to rework the parsing logic within getStartEpoch(), and and adjust the fixed binId sizes. Are we ok with this being a breaking change, or do we want to add complicated logic to handle both the new and old formats (a bit ugly)?
There was a problem hiding this comment.
I'd suggest you document an approach in an issue but don't worry about implementing it yet - tag the issue as "breaking changes"
|
@rfecher not sure I follow your comment about exposing it in SpatialTemporalDimensionalityTypeProvider. Isn't that handled via: |
#555