> Am 04.06.2020 um 14:15 schrieb Serge Stinckwich <serge.stinckw...@gmail.com>: > > OpenGIS is an object-oriented meta-model for GIS. There is no implementation > in Pharo but can give a good blueprint if we want to do something like that. > > I’m GMT+8. So a meeting Thursday at 9am for you is great for me (2pm for me). > It would be nice if Hernan can join also, but might be difficult with the > time zone difference. > If you could shift that to one hour later would be good. If it is a problem for Hernan I try to convince my family but later is better.
Norbert > Regards, > > Sent from my iPad > >> On 4 Jun 2020, at 18:50, Norbert Hartl <norb...@hartl.name> wrote: >> >> >> >>> Am 04.06.2020 um 12:31 schrieb Serge Stinckwich <serge.stinckw...@gmail.com >>> <mailto:serge.stinckw...@gmail.com>>: >>> >>> >>> >>> On Thu, Jun 4, 2020 at 4:11 PM Norbert Hartl <norb...@hartl.name >>> <mailto:norb...@hartl.name>> wrote: >>> I started this initiative for our company because we are in the mobility >>> bubsiness where maps and geo centric things are important. It is not >>> elaborate as a real GIS support but a start. So here my secret plan: >>> >>> >>> Thank you Norbert for your interest on that topic. >>> I put Etienne Delay because he is not ont the pharo-users mailing-list and >>> I'm working with him on GIS issues for CORMAS. >>> >>> - GeoJSON [1] was done because web services came up with that format to >>> exchange geo shape information. Furthermore database like MongoDB changed >>> their internal support for 2d/2dsphere indexes also to GeoJSON. There is a >>> package GeoJSON-Voyage which is start of a helper to easily store Geo data >>> in voyage-mongo. >>> >>> - I started to do a KML Reader [2] because besides GeoJSON that is a widely >>> used format. And this can be used in Google Earth which is the best free >>> Geo editor that I know. >>> >>> - As KML and GeoJSON use a similar model for representing geo shapes and >>> POIs I started to factor out that into the Geography package [3]. >>> >>> - At the moment in the Geography package there is only a 2D point class >>> GGPoint to have something to hold geo coordinates (there is also a 3D >>> variant). In the past I used Point as the class for these things but came >>> to the conclusion that there is a distinction between a point and geo point >>> when it comes to things like distance etc. So it is better to have them >>> separate. Into this model I want to morph the classes for LineStrings, >>> LinearRings, Polygons etc. from GeoJSON and KML to have a common foundation >>> for the basic geo shapes lines, multi-lines, closed multi-lines (=polygons) >>> etc. >>> >>> - As GGPoint is distinct to Point this is just the context where you use >>> it. The Geography package should be a companion to the Geometry package [4] >>> which I forked from TelescopeSt to make it a community package which is >>> good for this plan but also for roassal which uses the Geometry package. To >>> me the geoX model should be switched between Geometry and Geography >>> regarding to the context you want to work in being planar or spherical. >>> >>> - In my tools that I build this model classes have also gt-inspector >>> extension so the shapes can be viewed just by inspecting them. I'm fighting >>> with the roassal team to make it possible for geo coordinates which >>> conflicts at the moment with their defined thresholds. But with the >>> factoring the shapes into Geography I will move those extension to the >>> Geography package as well >>> >>> - I also implemented a polygon intersection algorithm (Weiler and Atherton) >>> which I will then incorporate in any of the GeoX packages >>> >>> >>> You have done a lot of work. And we add all the work done by Hernan on >>> supporting ESRI shapefiles, we have already a good start. >>> >>> Etienne also mention the OpenGIS model in this issue: >>> https://github.com/cormas/cormas/issues/139 >>> <https://github.com/cormas/cormas/issues/139> >>> >>> From what I understood, OpenGIS model crosscut many points of the Geography >>> package: >>> http://portal.opengeospatial.org/files/?artifact_id=25355 >>> <http://portal.opengeospatial.org/files/?artifact_id=25355> >>> >>> So these are the pieces that are there. The plan in text is: >>> >>> - Have a incarnation of a "point" and make that switch context from planar >>> to spherical >>> - Use planar treatment with the Geometry package (intersections etc.) >>> - Use this "point" to generate shapes either geometric or geographic >>> - Be able to read and write in common formats like GeoJSON and KML >>> - Make shapes be composable and inspectable with the existing tools >>> >>> I think GIS needs more but what we have is more than just a start. The >>> projection system with the current code is WGS84 for sure. If there are >>> other needs we need to think about this early. >>> >>> For everything else I'm open ears. Even for the idea of having a pharo-gis >>> github project to collect those things to a common place. But I like to >>> discuss GIS and not if it makes sense to have a all of these github repos. >>> >>> We can try to do an online meeting to discuss about that with Etienne and >>> other people interested by this topic. >>> We are mostly interested to have GIS support on CORMAS, so having a common >>> repository will definitively help us. >>> At the moment we are using Roassal2 for CORMAS visualisatin and we are >>> moving towards Roassal3. >> >> Good idea! I just created the Geography package because I felt the need for >> it. But if there is something better I would like to use this instead. I'm >> generally available the best at wednesdays and thursdays. Next week is >> already stuffed but if you propose some DateAndTimes I'm sure we find a >> match. Which timezone are you in at the moment? >> >> Norbert >> >>> Regards, >>> -- >>> Serge Stinckwich >>> https://twitter.com/SergeStinckwich <https://twitter.com/SergeStinckwich>
