GIS support for Pharo

- 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

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.

Norbert

[1] https://github.com/zweidenker/GeoJSON

[2] https://github.com/zweidenker/KML

[3] https://github.com/zweidenker/Geography

[4] https://github.com/pharo-contributions/Geometry

Am 04.06.2020 um 05:31 schrieb Serge Stinckwich <[hidden email]>:

Am 04.06.2020 um 12:31 schrieb Serge Stinckwich <[hidden email]>:

On Thu, Jun 4, 2020 at 4:11 PM Norbert Hartl <[hidden email]> 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

From what I understood, OpenGIS model crosscut many points of the Geography package:

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.

Regards,

-- 

Serge Stinckwic

h

https://twitter.com/SergeStinckwich



Am 04.06.2020 um 12:31 schrieb Serge Stinckwich <[hidden email]>:

On Thu, Jun 4, 2020 at 4:11 PM Norbert Hartl <[hidden email]> 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

From what I understood, OpenGIS model crosscut many points of the Geography package:

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 Stinckwic

h

https://twitter.com/SergeStinckwich

Am 04.06.2020 um 14:15 schrieb Serge Stinckwich <[hidden email]>:

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.

Regards,

Sent from my iPad

On 4 Jun 2020, at 18:50, Norbert Hartl <[hidden email]> wrote:



Am 04.06.2020 um 12:31 schrieb Serge Stinckwich <[hidden email]>:

On Thu, Jun 4, 2020 at 4:11 PM Norbert Hartl <[hidden email]> 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

From what I understood, OpenGIS model crosscut many points of the Geography package:

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 Stinckwic

h

https://twitter.com/SergeStinckwich