On 6/3/17 7:27 AM, Riyafa Abdul Hameed wrote:
Hi, So far I have been trying out Esri geometry api[1]. I parsed a csv file to read data in WKT format, converted it to OGCGeometry objects and calculated the average areas of the objects. Further I converted this OGCGeometry objects to WKB format and stored in a file. Then I read back the file and calculated the average areas of these objects. Thus I have learned the use of the api. Also since the project would focus on TDD(Test Driven Development) I have been focusing on writing AQL queries on calculating the average areas, Range query, k nearest neighbor and spatial joins using both the current support of spatial objects and future support of the spatial objects. These queries are to be used as integrations tests in the future. [1] https://github.com/Esri/geometry-api-java Thank you. Yours sincerely, Riyafa On 17 May 2017 at 23:35, Mike Carey <[email protected]> wrote:Sounds like a plan! :-) On 5/17/17 7:25 AM, Riyafa Abdul Hameed wrote: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) formatis 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 tokeep in mind - the input format (serialized format, e.g., how JSONrelatesto the spatial types) and the internal format (which in AsterixDB isa 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 Mikethatyouneed to study the current geo support first. It will be highly desirablefor your work to be compatible with the current support so that wecanseamlessly unify the underlying code without disrupting thehigh-levelAPI.As for the format, it would be nice to support both WKT and GeoJSONastheyare both widely used. However, I think we should start with GeoJSONsince 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 matterofwriting a different parse function.Esri library [https://github.com/Esri/geometry-api-java] supportsbothWKTand GeoJSON. You can study it and see if we can use it in ourproject.ThanksAhmed 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 leadingexpertonbig spatial data) to direct - I was just suggesting that step 0shouldbeto become familiar with what's already there currently, to have aworkingknowledge 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 textformat--correct me if I am mistaken. Hence initially we couldsupportotherGIS 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 inAsterixDB(curretn types and indexing and functions in queries) to getwarmedup.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 GSoCthistime.This being the community bonding period I am trying tofamiliarizemyselfwith 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 handlingdatamodelsfor 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 knowntext[1]andGeoJSON[2] and have been trying to figure out if implementingone ofthemwould suffice (if so which one) or if both needs to beimplemented.Ifbothneeds to be implemented we should decide which needs to beimplementedfirst. I was thinking of going for GeoJSON as it seems to have awiderusage.Any suggestions on how I should proceed with the project wouldbehighlyvalued. [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
