June 2020 - Pharo-users - lists.pharo.org

Re: [Pharo-users] ESRI ASCII raster format

by Ben Coman

Minimal... On Thu, 4 Jun 2020 at 21:00, Richard O'Keefe <raoknz(a)gmail.com> wrote: > Does anyone know of a collection of test files for this format? > You might be looking for smaller tests, but anyway.. https://github.com/richbl/esri-ascii-parser/tree/master/sample_data https://www.planlaufterrain.com/LiDAR-Data-and-FAQ/ https://library.carleton.ca/help/dem-formats https://data.gov.au/dataset/ds-dga-b2e1dfc6-2c7e-404a-a949-7e3e95fc4418/det… cheers -ben

June 4, 2020

Re: [Pharo-users] Few newbie questoins about Pharo/Smalltalk capabilities

by Ben Coman

On Tue, 2 Jun 2020 at 19:01, gustav_m <gustavmoist(a)gmail.com> wrote: > Hello! I don't know if this is a good place to ask this kind of questions, > but I haven't found other places where Smalltalk/Pharo experts hang out. > This is the place, and also Discord that others have linked to. > I'm a designer and unfortunately I know nothing about programming and > computation. I'm trying to change this right now. I'm looking for suitable > technology to learn and so far Pharo/Smalltalk looks very promising. To be > honest, it looks way too good to be true. And that's why I'm here, asking > you guys to disillusion me. > Your biggest disillusionment going to be less about Pharo versus any other language, and more about big ambitions exceed your (currently) small programming skills. I would encourage you to a step back from wanting to rush into using Pharo (or any language) for your work tools, and learn to program for its own sake. This will have a big impact on your level of frustration. First... - Do the MOOC... http://mooc.pharo.org/ - Read the Pharo By Example 5 and Learning Object Oriented Programming books... https://books.pharo.org/ These will give you a baseline programming skill transferable to any other programming language yo find interestin. And along the way, ask lots of questions on Discord. Then try Roassal. Pharo is a really great environment to learn to program in. At a minimum, learning "just a bit of Pharo" will give you an edge communicating with the programmers. We sometimes see refugees from other languages start using Pharo and exclaim "wow! programming is fun again!" After watching this video [https://youtu.be/AnrlSqtpOkw?t=550] my > imagination just went crazy. It looks like the Smalltalk system would be > also a perfect tool to give presentations to my superiors. > So to me Smalltalk looks like a holy grail. But again, my perception of it > is probably wrong and That video was a specific demo years ago that can't be done directly done in Pharo (or I expect any modern Smalltalk), but Pharo is still as close as you'll compared to language alternatives. While it can't be done exactly graphically, similar connections between objects are made in code one level lower. > I might be better of learning, for instance Dart+Flutter. > I don't know Dart, but hazard to say that Pharo is a better environment to "learn to program", and a lot of those skills will be transferable to Dart later anyhow, especially the software architectural skills you learn - which might be the hardest part of making a working system. > 1. As a designer I'm an aesthete. Is it possible to change the look of the > windows and the environment to ones liking? Or redesign the whole system to > not use windows at all? How moldable the environment is? > Mold-ability is where Pharo really excels compare to other languages. Most languages you have an Integrated Development Environment, that is separate from the application code you write, that is separate from the software you compile and distribute. With Pharo, the development environment, your application code, and your running application are all siblings occurring within the same environment. > 2. How well is Smalltalk/Pharo suited to handle different graphic animation > effects? As a designer I like to use animations to cue users. What about > sound effects? > > Also, as a hobby I'd like to try some (3.) generative art Look at Roassal. > Some people cry about Smalltalk being slow. So maybe I'd be wiser to learn > Processing (for > 3) and NetLogo (for 4) instead. This would be unfortunate as these are two > another technologies to learn. > "Slow" is very relative and application specific. The run-speed of an application needs to be balanced against the speed-to-create the application. If one language you could create a tool in a month, and another language you could create a tool twice as fast but it takes six months - which language is better? Original Smalltalk was "interpreted" only. Pharo has a "Just In Time Compiler". For most applications it will be fast enough. Any application that is not true, probably only a small part of you program is the bottle neck, and you redo that small part in a faster language and call it from Pharo. > I find the language itself, and especialy its minimalism/simplicity, so > elegant, that I'm thinking of printing the famous "postcard example" and > hanging it on a wall. The whole system, however, is humongous! It looks > like > learning (to be able to do anything interesting and non-trivial) will take > ages. > Any language's library ecosystem can feel huge. Pharo just happens to build in a lot of things into the Image. For example the "code" for every GUI element you are looking at is included int he Image (so you can modify it) which is missing from most other languages. It will take time, but so will getting proficiency in any other language. > So, what do you think? Should I invest my time here? Or is there a > different > technology that I should consider? > For trivial things, the only other thing I can think of that would suit your needs is Scratch (which was originally written in Smalltalk). But you may find in confining once you want to get more advanced. Overall it might be less effort sticking with Pharo. cheers -ben

June 4, 2020

Re: [Pharo-users] GIS support for Pharo

by StÃ©phane Ducasse

It would be good to have the related package under an umbrella. For example I can spend some time packaging hans package on github but only if it helps. So let me know. S > On 4 Jun 2020, at 14:15, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > 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 <norbert(a)hartl.name> wrote: >> >> ï»¿ >> >>> Am 04.06.2020 um 12:31 schrieb Serge Stinckwich <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>>: >>> >>> >>> >>> On Thu, Jun 4, 2020 at 4:11 PM Norbert Hartl <norbert(a)hartl.name <mailto:norbert@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> -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

June 4, 2020

Re: [Pharo-users] GIS support for Pharo

by StÃ©phane Ducasse

Hi hans Are you planning to publish on github or can we do it? You use it daily on which system? S. > On 4 Jun 2020, at 10:45, Baveco, Hans <hans.baveco(a)wur.nl> wrote: > > Would be an interesting project.. > An old link to possibly still useful code: > > http://wiki.squeak.org/squeak/3317 <http://wiki.squeak.org/squeak/3317> > > > Btw the shapefile support, from the ESRI spec, was done by me and is still available onhttp://www.squeaksource.com/@CUT95k_uXmPU4uXY/HCmgtrop <http://www.squeaksource.com/@CUT95k_uXmPU4uXY/HCmgtrop>. I use it daily. I may have some fixes/additions, but in general the code as provided works well (I suppose the code at smalltalkhub is still mostly the same). Some shapefile formats are still missing, mostly because I never encountered them.. > To read a complete shapefile one also needs to read dbf files. This was another substantial efforthttp://www.squeaksource.com/@Y4HhnL90iyA2TmAb/X0sPqshM <http://www.squeaksource.com/@Y4HhnL90iyA2TmAb/X0sPqshM>; luckily there was an older implementation.available to build upon. > Not sure whether nowadays there are other ways to read/write files old DBASE format files... > > Cheers, > > Hans Baveco > > > > > From: Serge Stinckwich <serge.stinckwich(a)gmail.com> > Sent: donderdag 4 juni 2020 5:32 > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: [Pharo-users] GIS support for Pharo > > Dear all, > > there was already some discussion in the list about GIS support for Pharo previously. > > Working on CORMAS multi-agent simulation platform: https://github.com/cormas/cormas <https://github.com/cormas/cormas> some developers feel the need to have more GIS support for Pharo. > > I know of existing GIS software: > - GeoJSON by Zweidenker: https://github.com/zweidenker/GeoJSON <https://github.com/zweidenker/GeoJSON> > - ESRI ascii raster, done by Stephane recently: https://github.com/Ducasse/ESRI-ASCII-Raster <https://github.com/Ducasse/ESRI-ASCII-Raster> > - shapefile support by Hernan: http://smalltalkhub.com/#!/~hernan/Shapes <http://smalltalkhub.com/#!/~hernan/Shapes> > (to be moved to github) > - I found this project also: http://www.squeaksource.com/gekon.html <http://www.squeaksource.com/gekon.html> > > I know that Etienne Delay is also interested by GIS support and propose to implement OpenGIS model support:https://github.com/cormas/cormas/issues/139 <https://github.com/cormas/cormas/issues/139> > > Can we try to unite and maybe create a pharo-GIS organization on github to federate our efforts? > > Cheers, > -- > Serge Stinckwic > h > https://twitter.com/SergeStinckwich <https://twitter.com/SergeStinckwich> -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

June 4, 2020

Re: [Pharo-users] ESRI ASCII raster format

by Richard O'Keefe

Does anyone know of a collection of test files for this format? On Thu, 4 Jun 2020 at 01:39, Richard O'Keefe <raoknz(a)gmail.com> wrote: > Reading and writing the format looks pretty straightforward; > the question is, what is the internal representation? > These things are basically decorated 2D number arrays. > It is said in various places that the cell entries are > stored as integers, but not what precision, nor what mapping > there might be between internal and external numbers. > > > On Wed, 3 Jun 2020 at 14:02, Serge Stinckwich <serge.stinckwich(a)gmail.com> > wrote: > >> Dear all, >> >> I'm looking for an implementation of ESRI ASCII raster format: >> >> http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/ESRI_ASCII_ra… >> >> We are looking for such an implementation for CORMAS: >> https://github.com/cormas/cormas/issues/135 >> >> Thank you. >> Regards, >> -- >> Serge Stinckwic >> h >> https://twitter.com/SergeStinckwich >> >

June 4, 2020

Re: [Pharo-users] GIS support for Pharo

by Norbert Hartl

> Am 04.06.2020 um 14:15 schrieb Serge Stinckwich <serge.stinckwich(a)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 <norbert(a)hartl.name> wrote: >> >> ï»¿ >> >>> Am 04.06.2020 um 12:31 schrieb Serge Stinckwich <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>>: >>> >>> >>> >>> On Thu, Jun 4, 2020 at 4:11 PM Norbert Hartl <norbert(a)hartl.name <mailto:norbert@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>

June 4, 2020

Re: [Pharo-users] GIS support for Pharo

by HernÃ¡n Morales Durand

El jue., 4 jun. 2020 a las 9:16, Serge Stinckwich (< serge.stinckwich(a)gmail.com>) escribiÃ³: > 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. > > You mean next Thursday 11/06 ? On discord cormas channel? I could connect no problem. Cheers, HernÃ¡n > Regards, > > Sent from my iPad > > On 4 Jun 2020, at 18:50, Norbert Hartl <norbert(a)hartl.name> wrote: > > ï»¿ > > Am 04.06.2020 um 12:31 schrieb Serge Stinckwich < > serge.stinckwich(a)gmail.com>: > > > > On Thu, Jun 4, 2020 at 4:11 PM Norbert Hartl <norbert(a)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 > > 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 > > >

June 4, 2020

Re: [Pharo-users] GIS support for Pharo

by Serge Stinckwich

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 <norbert(a)hartl.name> wrote: > > ï»¿ > >> Am 04.06.2020 um 12:31 schrieb Serge Stinckwich <serge.stinckwich(a)gmail.com>: >> >> >> >>> On Thu, Jun 4, 2020 at 4:11 PM Norbert Hartl <norbert(a)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 >> >> 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 Stinckwich >> https://twitter.com/SergeStinckwich >

June 4, 2020

Re: [Pharo-users] GIS support for Pharo

by Norbert Hartl

> Am 04.06.2020 um 12:31 schrieb Serge Stinckwich <serge.stinckwich(a)gmail.com>: > > > > On Thu, Jun 4, 2020 at 4:11 PM Norbert Hartl <norbert(a)hartl.name <mailto:norbert@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>

June 4, 2020

Re: [Pharo-users] GIS support for Pharo

by Serge Stinckwich

Really nice visualisation ! On Thu, Jun 4, 2020 at 4:45 PM Norbert Hartl <norbert(a)hartl.name> wrote: > Forgot to say. I also started to do an OSM renderer two years ago. > > > I tried to do in Bloc but got no support and it got stuck. A few weeks ago > I put this again on my list. Talking to Stef I saw that I might not need to > interaction support etc. at the beginning and can do this on top of Athens. > > FYI, > > Norbert > > Am 04.06.2020 um 10:11 schrieb Norbert Hartl <norbert(a)hartl.name>: > > 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: > > - 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 > > 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 < > serge.stinckwich(a)gmail.com>: > > Dear all, > > there was already some discussion in the list about GIS support for Pharo > previously. > > Working on CORMAS multi-agent simulation platform: > https://github.com/cormas/cormas some developers feel the need to have > more GIS support for Pharo. > > I know of existing GIS software: > - GeoJSON by Zweidenker: https://github.com/zweidenker/GeoJSON > - ESRI ascii raster, done by Stephane recently: > https://github.com/Ducasse/ESRI-ASCII-Raster > - shapefile support by Hernan: http://smalltalkhub.com/#!/~hernan/Shapes > (to be moved to github) > - I found this project also: http://www.squeaksource.com/gekon.html > > I know that Etienne Delay is also interested by GIS support and propose to > implement OpenGIS model support: > https://github.com/cormas/cormas/issues/139 > > Can we try to unite and maybe create a pharo-GIS organization on github to > federate our efforts? > > Cheers, > -- > Serge Stinckwic > h > https://twitter.com/SergeStinckwich > > > > -- Serge Stinckwic âhâ https://twitter.com/SergeStinckwich â

June 4, 2020