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 > > >
