Hi, Through a discussion that I had with Ahmed, I have been able to clarify the following points:
- A new data type which is known as Geometry would be supported - Esri library[1] shall be used for parsing and operating on WKT and GeoJSON formats - Functions such as parseWKT and parseGeoJSON would be used for parsing text in these formats to Geometry datatype - Internally Geometry datatype would be represented in WKB(Well Known Binary) format - Functions shall be written(if time permits) to convert currently supported datatypes such as point, polygon, circle, and rectangle to Geometry datatype [1] https://github.com/Esri/geometry-api-java/blob/master/src/main/java/com/esri/core/geometry/Geometry.java Thank you. Yours sincerely, Riyafa On 15 May 2017 at 20:13, Riyafa Abdul Hameed <[email protected]> wrote: > Hi, > > In a different thread Preston had asked about the format of the datatypes. > As I gather from this discussion current format supported in AsterixDB is > different from WKT or GeoJSON. So the tasks in resolving this issue, does > it involve supporting the new Geo objects in the *current format* and > then in GeoJSON and/or WKT or is it about supporting all the GIS objects in > GeoJSON and/or WKT *only*? > (I have already started writing code to support triangle so as to get the > hang of implementation details) > > Thank you. > > Yours sincerely, > Riyafa > > On 14 May 2017 at 09:36, Riyafa Abdul Hameed <[email protected]> wrote: > >> Hi, >> >> I have been exploring the current implementations of point, polygon, >> circle, and rectangle. These have been implemented as Primitive Types >> <https://ci.apache.org/projects/asterixdb/datamodel.html#PrimitiveTypes> >> and like Ahmed mentioned they have have an internal >> representation in WKB. The data types that require to be implemented are: >> >> - MultiPoint >> - MultiLineString >> - MultiPolygon >> - Triangle >> - CircularString >> - Curve >> - MultiCurve >> - CompoundCurve >> - CurvePolygon >> - Surface >> - MultiSurface >> - PolyhedralSurface >> - TIN (Triangulated irregular network) >> - GeometryCollection >> >> As I understand by looking at the implementation of point and poygon they >> are implemented as functions and builtintypes in AsterixDB internally. So I >> thought of initially implementing these new types internally. I thought of >> starting with Triangle and once I get the hang of it by having the >> implementation reviewed I can continue with the implementation of the >> remaining types. As for using Esri API, since it is not currently used I >> thought it can come handy when implementing the required operations on each >> of these data types. >> >> Thank you. >> >> Yours sincerely, >> >> Riyafa >> >> >> >> >> On 14 May 2017 at 02:56, Ahmed Eldawy <[email protected]> wrote: >> >>> The notice of the two formats is important. The GeoJSON (or WKT) format >>> is >>> only for importing text files. AsterixDB should have an internal >>> representation for geometries. The only standard I know in this matter is >>> Well-known Binary (WKB) which is also supported by Esri API and JTS. >>> @Wail: AsterixDB is not supposed to automatically detect that a field is >>> GeoJSON. The user should provide this information while importing a file, >>> probably, by defining the schema with a Geometry field. >>> >>> Thanks >>> Ahmed >>> >>> On Fri, May 12, 2017 at 2:31 PM, Wail Alkowaileet <[email protected]> >>> wrote: >>> >>> > One small thing about GeoJSON ... >>> > >>> > From the JSON/ADM parser perspective, GeoJSON is still JSON. >>> > "Disambiguating" or distinguishing between them might not be a >>> > straightforward process. Getting GeoJSON parsed into AsterixDB internal >>> > geometries would probably be the first step... >>> > >>> > On Fri, May 12, 2017 at 11:15 PM, Mike Carey <[email protected]> >>> wrote: >>> > >>> > > Just to chime in briefly on the "format" thread - there are two >>> formats >>> > to >>> > > keep in mind - the input format (serialized format, e.g., how JSON >>> > relates >>> > > to the spatial types) and the internal format (which in AsterixDB is >>> a >>> > > different, more efficient, binary format). We can look at both in >>> the >>> > > project. Also important are the OPERATIONS that go with the format >>> (i.e., >>> > > the functions that we'll have in the query language for operating on, >>> > > writing predicates about, etc., the spatial data). >>> > > >>> > > Cheers, >>> > > >>> > > Mike >>> > > >>> > > >>> > > >>> > > On 5/11/17 2:28 PM, Ahmed Eldawy wrote: >>> > > >>> > >> Hi Riyafa, >>> > >> >>> > >> I'm glad you started looking into the details. I agree with Mike >>> that >>> > you >>> > >> need to study the current geo support first. It will be highly >>> desirable >>> > >> for your work to be compatible with the current support so that we >>> can >>> > >> seamlessly unify the underlying code without disrupting the >>> high-level >>> > >> API. >>> > >> As for the format, it would be nice to support both WKT and GeoJSON >>> as >>> > >> they >>> > >> are both widely used. However, I think we should start with GeoJSON >>> > since >>> > >> it is becoming more popular with modern devices, e.g., GPS, smart >>> > phones, >>> > >> and IoT sensors. Later, we can support WKT as well. It will be a >>> matter >>> > of >>> > >> writing a different parse function. >>> > >> Esri library [https://github.com/Esri/geometry-api-java] supports >>> both >>> > >> WKT >>> > >> and GeoJSON. You can study it and see if we can use it in our >>> project. >>> > >> >>> > >> Thanks >>> > >> Ahmed >>> > >> >>> > >> On Wed, May 10, 2017 at 7:11 AM, Mike Carey <[email protected]> >>> wrote: >>> > >> >>> > >> I will leave it to the official GSC mentor (who's also a leading >>> expert >>> > on >>> > >>> big spatial data) to direct - I was just suggesting that step 0 >>> should >>> > be >>> > >>> to become familiar with what's already there currently, to have a >>> > working >>> > >>> knowledge of that as background. >>> > >>> >>> > >>> :-) >>> > >>> >>> > >>> Looking forward to seeing this project unfold! >>> > >>> >>> > >>> Cheers, >>> > >>> >>> > >>> Mike >>> > >>> >>> > >>> >>> > >>> >>> > >>> On 5/9/17 10:14 PM, Riyafa Abdul Hameed wrote: >>> > >>> >>> > >>> Hi, >>> > >>>> >>> > >>>> As I understand by playing with current support of GIS objects( >>> point, >>> > >>>> polygon, circle, and rectangle) is similar to the Well known text >>> > >>>> format--correct me if I am mistaken. Hence initially we could >>> support >>> > >>>> other >>> > >>>> GIS objects in WKT and support GeoJSON if time permits. >>> > >>>> >>> > >>>> Thank you. >>> > >>>> Yours sincerely, >>> > >>>> Riyafa >>> > >>>> >>> > >>>> On 8 May 2017 at 23:31, Mike Carey <[email protected]> wrote: >>> > >>>> >>> > >>>> I would also suggest playing with the current geo support in >>> AsterixDB >>> > >>>> >>> > >>>>> (curretn types and indexing and functions in queries) to get >>> warmed >>> > up. >>> > >>>>> Welcome aboard...!! >>> > >>>>> >>> > >>>>> Cheers, >>> > >>>>> >>> > >>>>> Mike >>> > >>>>> >>> > >>>>> >>> > >>>>> On 5/8/17 8:51 AM, Riyafa Abdul Hameed wrote: >>> > >>>>> >>> > >>>>> Hi, >>> > >>>>> >>> > >>>>>> I have been selected to contribute to the issue ASTERIXDB-1371 >>> > >>>>>> <https://issues.apache.org/jira/browse/ASTERIXDB-1371> for GSoC >>> > this >>> > >>>>>> time. >>> > >>>>>> This being the community bonding period I am trying to >>> familiarize >>> > >>>>>> myself >>> > >>>>>> with the code base of AsterixDB and to get a grasp of the task. >>> > >>>>>> >>> > >>>>>> I am under the impression that the package * >>> org.apache.asterix.om >>> > >>>>>> <http://org.apache.asterix.om> *has the classes for handling >>> data >>> > >>>>>> models >>> > >>>>>> for AsterixDB and have been looking into them to figure out the >>> > >>>>>> implementation details. Please correct me if I am mistaken. >>> > >>>>>> >>> > >>>>>> I have also been reading on the specification for well known >>> text[1] >>> > >>>>>> and >>> > >>>>>> GeoJSON[2] and have been trying to figure out if implementing >>> one of >>> > >>>>>> them >>> > >>>>>> would suffice (if so which one) or if both needs to be >>> implemented. >>> > If >>> > >>>>>> both >>> > >>>>>> needs to be implemented we should decide which needs to be >>> > implemented >>> > >>>>>> first. I was thinking of going for GeoJSON as it seems to have a >>> > wider >>> > >>>>>> usage. >>> > >>>>>> >>> > >>>>>> Any suggestions on how I should proceed with the project would >>> be >>> > >>>>>> highly >>> > >>>>>> valued. >>> > >>>>>> >>> > >>>>>> [1] http://docs.opengeospatial.org/is/12-063r5/12-063r5.html >>> > >>>>>> [2] https://tools.ietf.org/html/rfc7946 >>> > >>>>>> >>> > >>>>>> Thank you. >>> > >>>>>> >>> > >>>>>> Yours sincerely, >>> > >>>>>> Riyafa >>> > >>>>>> >>> > >>>>>> >>> > >>>>>> >>> > >>>>>> >>> > > >>> > >>> > >>> > -- >>> > >>> > *Regards,* >>> > Wail Alkowaileet >>> > >>> >> >> >
