- Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo Success story - MultiCity

by Norbert Hartl

> Am 16.07.2015 um 12:59 schrieb phil(a)highoctane.be: > > One question about Mongo. > > How do you handle HA (High Availability) in Pharo? > I don't. > The current driver (MongoTalk) connects to one single mongod. > > I haven't seen any support for replicasets and identifying who is the mongod to write to in MongoTalk (this support is built in any Python, Ruby, ... driver they do provide, including sharding support and GridFS). > As far as I know there is no support for all of these. It would be really good to have them. But if nobody contributes it may be not needed after all. > Also, I've been experiencing a couple of protocol errors when working with mongod under some scenarios (unrecognized command coming back in the wire protocol). Looks like MongoTalk and mongod were out of sync on the wire protocol. > You need to be careful because the mongo connection is a single stream aligned request by request. If another thread writes on the stream at the same time you will experience what you call "out of sync". Norbert > Thanks and kudos for one more nice application! > > Phil > > > On Thu, Jul 16, 2015 at 12:36 PM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > Hi Torsten, > > > Am 15.07.2015 um 22:51 schrieb Torsten Bergmann <astares(a)gmx.de <mailto:astares@gmx.de>>: > > > > Another story from 2Denker is up: http://pharo.org/success/MultiCity <http://pharo.org/success/MultiCity> > > > > Client seems to be done using Amber when I check the login page which was > > styled with Bootstrap. Server in Pharo with Nginx. I guess you use Mongo as > > DB (with Voyage or without). > > > > @Norbert/@Marcus: if possible can you share with us a few more technical details about > > the technologies/stack used. Also about size (LOC, users, nr of images) > > and pitfalls ... > > > > There is always something one can learn from the experience of others. > > sure I can give some insight in the project. > > For the admin client we use amber plus bootstrap. The backend for this is a pharo image with voyage. As you can see in the screenshot there is a geo location entered. That can be searched afterwards because mongo provides geo spatial indexes. > > The project is built upon a service we provide at 2denker. The service is a registry for app installations, users and message tokens. We provide libraries for ios, android and windows mobile that registers the app, assigns a user, requests a message token from the user and stores it. The service is used for notifying the user at return of the car. You then get a notification containing the time and price of your car rental. > > The architecture of our infrastructure is event based. Meaning that e.g. the installation registration service sends events to a central event bus like image. This stores the events in elasticsearch and provides the ability to register for events. > > What we had to do for this project? We've built an image that on the one hand serves the request of the client admin interface. On the other hand it registers at the event server for a certain kind of event. This event is triggered by the car return and piggybacks the geo location where the car has been left. When such an event travels through our system the event server sees a match and calls the image. The image extracts the geo information and searches the database for available advertisements. If one is found and conditions are met an additional message is sent. > > That's roughly it. In the whole process there are 8 pharo images involved but 2 are for redundancy so it is 6 different images. The rest is a mongo database and an elasticsearch database. If you want to know anything more don't hesitate to ask. > > Norbert > > > >

July 16, 2015

Re: [Pharo-users] PharoJS

by Noury Bouraqadi

> On 15 Jul 2015, at 15:37, Andy Burnett <andy.burnett(a)knowinnovation.com> wrote: > > One question. When I execute 1+1 on the Pharo (pink) playground, I see the code appearing in the web browser log, but it doesn't appear to execute. Is it supposed to, or at this stage is it just showing that it made it over to the web browser? > It does actually execute on the browser, but 1+1 has no side effect :-). You can try to call native javascript object to see stuff changing. For example, you can evaluate the following> console native_log: 'Hello from Smalltalk'. "Displays the string in the console of the browser" window native_alert: 'This is cool'. "Opens an alert window on the browser" Note: You need to load version 51 (just pushed it to SmalltalkHub) that fixes a bug in the PharoJS workspace. Noury

July 16, 2015

Re: [Pharo-users] Pharo Success story - MultiCity

by phil＠highoctane.be

One question about Mongo. How do you handle HA (High Availability) in Pharo? The current driver (MongoTalk) connects to one single mongod. I haven't seen any support for replicasets and identifying who is the mongod to write to in MongoTalk (this support is built in any Python, Ruby, ... driver they do provide, including sharding support and GridFS). Also, I've been experiencing a couple of protocol errors when working with mongod under some scenarios (unrecognized command coming back in the wire protocol). Looks like MongoTalk and mongod were out of sync on the wire protocol. Thanks and kudos for one more nice application! Phil On Thu, Jul 16, 2015 at 12:36 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Hi Torsten, > > > Am 15.07.2015 um 22:51 schrieb Torsten Bergmann <astares(a)gmx.de>: > > > > Another story from 2Denker is up: http://pharo.org/success/MultiCity > > > > Client seems to be done using Amber when I check the login page which was > > styled with Bootstrap. Server in Pharo with Nginx. I guess you use Mongo > as > > DB (with Voyage or without). > > > > @Norbert/@Marcus: if possible can you share with us a few more technical > details about > > the technologies/stack used. Also about size (LOC, users, nr of images) > > and pitfalls ... > > > > There is always something one can learn from the experience of others. > > sure I can give some insight in the project. > > For the admin client we use amber plus bootstrap. The backend for this is > a pharo image with voyage. As you can see in the screenshot there is a geo > location entered. That can be searched afterwards because mongo provides > geo spatial indexes. > > The project is built upon a service we provide at 2denker. The service is > a registry for app installations, users and message tokens. We provide > libraries for ios, android and windows mobile that registers the app, > assigns a user, requests a message token from the user and stores it. The > service is used for notifying the user at return of the car. You then get a > notification containing the time and price of your car rental. > > The architecture of our infrastructure is event based. Meaning that e.g. > the installation registration service sends events to a central event bus > like image. This stores the events in elasticsearch and provides the > ability to register for events. > > What we had to do for this project? We've built an image that on the one > hand serves the request of the client admin interface. On the other hand it > registers at the event server for a certain kind of event. This event is > triggered by the car return and piggybacks the geo location where the car > has been left. When such an event travels through our system the event > server sees a match and calls the image. The image extracts the geo > information and searches the database for available advertisements. If one > is found and conditions are met an additional message is sent. > > That's roughly it. In the whole process there are 8 pharo images involved > but 2 are for redundancy so it is 6 different images. The rest is a mongo > database and an elasticsearch database. If you want to know anything more > don't hesitate to ask. > > Norbert > > > >

July 16, 2015

Re: [Pharo-users] Pharo Success story - MultiCity

by Norbert Hartl

Hi Torsten, > Am 15.07.2015 um 22:51 schrieb Torsten Bergmann <astares(a)gmx.de>: > > Another story from 2Denker is up: http://pharo.org/success/MultiCity > > Client seems to be done using Amber when I check the login page which was > styled with Bootstrap. Server in Pharo with Nginx. I guess you use Mongo as > DB (with Voyage or without). > > @Norbert/@Marcus: if possible can you share with us a few more technical details about > the technologies/stack used. Also about size (LOC, users, nr of images) > and pitfalls ... > > There is always something one can learn from the experience of others. sure I can give some insight in the project. For the admin client we use amber plus bootstrap. The backend for this is a pharo image with voyage. As you can see in the screenshot there is a geo location entered. That can be searched afterwards because mongo provides geo spatial indexes. The project is built upon a service we provide at 2denker. The service is a registry for app installations, users and message tokens. We provide libraries for ios, android and windows mobile that registers the app, assigns a user, requests a message token from the user and stores it. The service is used for notifying the user at return of the car. You then get a notification containing the time and price of your car rental. The architecture of our infrastructure is event based. Meaning that e.g. the installation registration service sends events to a central event bus like image. This stores the events in elasticsearch and provides the ability to register for events. What we had to do for this project? We've built an image that on the one hand serves the request of the client admin interface. On the other hand it registers at the event server for a certain kind of event. This event is triggered by the car return and piggybacks the geo location where the car has been left. When such an event travels through our system the event server sees a match and calls the image. The image extracts the geo information and searches the database for available advertisements. If one is found and conditions are met an additional message is sent. That's roughly it. In the whole process there are 8 pharo images involved but 2 are for redundancy so it is 6 different images. The rest is a mongo database and an elasticsearch database. If you want to know anything more don't hesitate to ask. Norbert

July 16, 2015

Re: [Pharo-users] Openstreetmap on Pharo

by Sven Van Caekenberghe

> On 16 Jul 2015, at 11:04, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2015-07-16 10:52 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Hi! > > The OpenStreetMap support in Roassal works pretty wellâ¦ The easiest way to start is probably take the latest version of Moose. Open the example browser and look for OpenStreetMap Integration. > > Thierry, although pretty cool, I have the impression the integration could be better. Here is a wish list: > - Tile caching > > This one is working! Ok, with latency issues, but we don't know where they are (with Sven, we suspected they were not in the caching code). Yes, there was an issue that seemed to be in the general Pharo drawing, not the tile accessing/caching, but we could not find it. We ended with the conclusion: Alex has to take a look ;-) > - Predictive zoom level. E.g., If I click twice on the zoomin button, it is likely that I will click a third time. So preloading the needed tile would be good > > Sure. There is also the idea of preloading around the current view so that you can drag left or right without delay. But at one point, you look at the code complexity and you say... hum, is that really worth it? I agree, it looks like a good idea, but it probably isn't: you would be loading way too much. > Again Thierry and Onil, thanks for this working piece of work. This is fantastic! > > The only true weakness we have is to have to go javascript to use it as a web interface :( > > Thierry > > > Cheers, > Alexandre > > > On Jul 16, 2015, at 7:51 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > Le 16/07/2015 03:59, Hilaire a Ã©crit : > >> Hi Thierry, > >> > >> This is what I did, I pick up latest Moose, and play a bit. It is nice > >> indeed. > >> > >> A few remarks > >> - loading the tiles is slow, does it comes from me? I am right on the > >> local tile server in Hsinchu.. I am not sure the right tile server is > >> used. a.tile.openstreetmap.org > > > > Do you need a dedicated tile server or the generic ones? We had an issue trying to accelerate tile loading when improving that part during PharoDays. > > > > I'll have a look at Moose to see which version of Roassal you are dealing with. > > > >> - the graphic quality is not optimal, blurred > > > > RTOSM interpolates between tiles zoom levels to gives you more freedom when zooming; this may comes with a slightly degraded image quality. Unless it is heavily blurred in which case it is something else. A screenshot? > > > >> - I have a hard time to find live programming (in fact I failed): trying > >> to get on an inspector was not obvious, then I don't know what I can do > >> to modify the model and its view > > > > This is more a Moose problem then. > > > >> - one RTOSM example fails because of fuel version > > > > There is a problem with the version of Roassal you are using. I remember correcting that a while ago. > > > >> - examples #exampleSeismOnEarthLive #exampleSeismOnEarthLiveZoom fail also. > > > > Yes, the links used to download the data (from the usgs if I remember correctly) have changed recently; there was a discussion on the mailing list not long ago (on pharo-dev or moose-dev); I don't know in which version of Roassal this was corrected. > > > > Thierry > > > >> > >> Thanks for the tips > >> > >> Hilaire > >> > >> Le 16/07/2015 02:28, Thierry Goubier a Ã©crit : > >>> Hi Hilaire, > >>> > >>> OSM tiles support was added to Roassal, and demonstrated in two videos > >>> [1][2]. The context of the work was presented at FOSDEM [3]. > >>> > >>> In the pillarhub document, I demonstrated how to query the raw OSM > >>> data; we made sure that the tile support and georeferenced data could > >>> go on the same level, and be precise to the pixel to the underlying > >>> tile rendering. > >>> > >>> I'm sure all this works in Pharo4, just try the RTOSM examples! There > >>> is probably a way to make it interactive with data downloading and a > >>> playground, using the sample code present in the pillarhub document. > >>> > >>> [2] is a bit different, it uses a sensor network design tool and > >>> simulateur which requires VisualWorks, Occam and/or a Cuda GPU :). But > >>> it makes for an interesting demo / talk if it is your field, just > >>> contact Onil. > >>> > >>> Thierry > >>> > >>> [1] https://www.youtube.com/watch?v=6zoGIsQaGUo > >>> [2] https://www.youtube.com/watch?v=sMB7DG-lbiU > >>> [3] https://archive.fosdem.org/2015/schedule/event/cirela/ > >>> > >>> > >>> Le 15/07/2015 19:16, Hilaire a Ã©crit : > >>>> Hi, > >>>> > >>>> In a few weeks I will give a speech in Taiwan at NCHC[1] about Pharo, my > >>>> intend is to present release 4. I already did speeches there in the past > >>>> about Pharo, but I have a hard time to raise interest to the point > >>>> people want to jump in. > >>>> But I hope to have an angle this time because NCHC recently offers a > >>>> server and the hosting for an openstreetmap tile server (the first in > >>>> Asia by the way), and there is high interest here in Taiwan about OSM > >>>> related stuff. > >>>> > >>>> I read here, job has been done with Roassal and OSM, but it is not clear > >>>> for me how to get in using OSM within Pharo. I am particularly > >>>> interested in providing an interactive demo where live programming shows > >>>> its value. > >>>> > >>>> I have found these pointers bellow. I am interested by any additional > >>>> tips and url, and particularly the compatibility with Pharo4. > >>>> > >>>> https://github.com/fstephany/OSMMaps > >>>> http://pillarhub.pharocloud.com/hub/ThierryGoubier/5y08m9uu71o8i7a35ijwr766p > >>>> > >>>> > >>>> > >>>> > >>>> Thanks > >>>> > >>>> Hilaire > >>>> > >>>> > >>>> [1] > >>>> https://en.wikipedia.org/wiki/National_Center_for_High-Performance_Computing > >>>> > >>>> > >>> > >>> > >>> > >> > >> > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

July 16, 2015

Re: [Pharo-users] Openstreetmap on Pharo

by Stephan Eggermont

On 16-07-15 10:53, Thierry Goubier wrote: > More, RTOSM now will do a file-based cache of the tiles, so, if you > prepare the demo beforehand, then your Pharo will have preloaded the > tiles and will not tap into the tile servers. Thanks, that is a welcome improvement. Stephan

July 16, 2015

Re: [Pharo-users] Openstreetmap on Pharo

by Thierry Goubier

2015-07-16 10:52 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Hi! > > The OpenStreetMap support in Roassal works pretty wellâ¦ The easiest way to > start is probably take the latest version of Moose. Open the example > browser and look for OpenStreetMap Integration. > > Thierry, although pretty cool, I have the impression the integration could > be better. Here is a wish list: > - Tile caching > This one is working! Ok, with latency issues, but we don't know where they are (with Sven, we suspected they were not in the caching code). > - Predictive zoom level. E.g., If I click twice on the zoomin > button, it is likely that I will click a third time. So preloading the > needed tile would be good > Sure. There is also the idea of preloading around the current view so that you can drag left or right without delay. But at one point, you look at the code complexity and you say... hum, is that really worth it? > > Again Thierry and Onil, thanks for this working piece of work. This is > fantastic! > The only true weakness we have is to have to go javascript to use it as a web interface :( Thierry > > Cheers, > Alexandre > > > On Jul 16, 2015, at 7:51 AM, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > Le 16/07/2015 03:59, Hilaire a Ã©crit : > >> Hi Thierry, > >> > >> This is what I did, I pick up latest Moose, and play a bit. It is nice > >> indeed. > >> > >> A few remarks > >> - loading the tiles is slow, does it comes from me? I am right on the > >> local tile server in Hsinchu.. I am not sure the right tile server is > >> used. a.tile.openstreetmap.org > > > > Do you need a dedicated tile server or the generic ones? We had an issue > trying to accelerate tile loading when improving that part during PharoDays. > > > > I'll have a look at Moose to see which version of Roassal you are > dealing with. > > > >> - the graphic quality is not optimal, blurred > > > > RTOSM interpolates between tiles zoom levels to gives you more freedom > when zooming; this may comes with a slightly degraded image quality. Unless > it is heavily blurred in which case it is something else. A screenshot? > > > >> - I have a hard time to find live programming (in fact I failed): trying > >> to get on an inspector was not obvious, then I don't know what I can do > >> to modify the model and its view > > > > This is more a Moose problem then. > > > >> - one RTOSM example fails because of fuel version > > > > There is a problem with the version of Roassal you are using. I remember > correcting that a while ago. > > > >> - examples #exampleSeismOnEarthLive #exampleSeismOnEarthLiveZoom fail > also. > > > > Yes, the links used to download the data (from the usgs if I remember > correctly) have changed recently; there was a discussion on the mailing > list not long ago (on pharo-dev or moose-dev); I don't know in which > version of Roassal this was corrected. > > > > Thierry > > > >> > >> Thanks for the tips > >> > >> Hilaire > >> > >> Le 16/07/2015 02:28, Thierry Goubier a Ã©crit : > >>> Hi Hilaire, > >>> > >>> OSM tiles support was added to Roassal, and demonstrated in two videos > >>> [1][2]. The context of the work was presented at FOSDEM [3]. > >>> > >>> In the pillarhub document, I demonstrated how to query the raw OSM > >>> data; we made sure that the tile support and georeferenced data could > >>> go on the same level, and be precise to the pixel to the underlying > >>> tile rendering. > >>> > >>> I'm sure all this works in Pharo4, just try the RTOSM examples! There > >>> is probably a way to make it interactive with data downloading and a > >>> playground, using the sample code present in the pillarhub document. > >>> > >>> [2] is a bit different, it uses a sensor network design tool and > >>> simulateur which requires VisualWorks, Occam and/or a Cuda GPU :). But > >>> it makes for an interesting demo / talk if it is your field, just > >>> contact Onil. > >>> > >>> Thierry > >>> > >>> [1] https://www.youtube.com/watch?v=6zoGIsQaGUo > >>> [2] https://www.youtube.com/watch?v=sMB7DG-lbiU > >>> [3] https://archive.fosdem.org/2015/schedule/event/cirela/ > >>> > >>> > >>> Le 15/07/2015 19:16, Hilaire a Ã©crit : > >>>> Hi, > >>>> > >>>> In a few weeks I will give a speech in Taiwan at NCHC[1] about Pharo, > my > >>>> intend is to present release 4. I already did speeches there in the > past > >>>> about Pharo, but I have a hard time to raise interest to the point > >>>> people want to jump in. > >>>> But I hope to have an angle this time because NCHC recently offers a > >>>> server and the hosting for an openstreetmap tile server (the first in > >>>> Asia by the way), and there is high interest here in Taiwan about OSM > >>>> related stuff. > >>>> > >>>> I read here, job has been done with Roassal and OSM, but it is not > clear > >>>> for me how to get in using OSM within Pharo. I am particularly > >>>> interested in providing an interactive demo where live programming > shows > >>>> its value. > >>>> > >>>> I have found these pointers bellow. I am interested by any additional > >>>> tips and url, and particularly the compatibility with Pharo4. > >>>> > >>>> https://github.com/fstephany/OSMMaps > >>>> > http://pillarhub.pharocloud.com/hub/ThierryGoubier/5y08m9uu71o8i7a35ijwr766p > >>>> > >>>> > >>>> > >>>> > >>>> Thanks > >>>> > >>>> Hilaire > >>>> > >>>> > >>>> [1] > >>>> > https://en.wikipedia.org/wiki/National_Center_for_High-Performance_Computing > >>>> > >>>> > >>> > >>> > >>> > >> > >> > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

July 16, 2015

Re: [Pharo-users] Openstreetmap on Pharo

by Thierry Goubier

2015-07-16 9:50 GMT+02:00 Hilaire <hilaire(a)drgeo.eu>: > Le 16/07/2015 13:51, Thierry Goubier a Ã©crit : > > > > Do you need a dedicated tile server or the generic ones? We had an > > issue trying to accelerate tile loading when improving that part > > during PharoDays. > > I am wondering if the used server is the geographically closest one. > No. We did a very basic query system on one of the overall tile servers at the beginning. Sven improved that a lot by restricting the number of concurrent requests for tiles and load balancing among servers (a, b, c). Given how the system is written, I suspect that if one of the tile servers is faster, it will get more requests. More, RTOSM now will do a file-based cache of the tiles, so, if you prepare the demo beforehand, then your Pharo will have preloaded the tiles and will not tap into the tile servers. We still have unexpected latency issues, but I haven't added a time trace analysis to the Jejak tracer. It's on my todo list. Thierry > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > http://google.com/+DrgeoEu > > > >

July 16, 2015

Re: [Pharo-users] Openstreetmap on Pharo

by Alexandre Bergel

Hi! The OpenStreetMap support in Roassal works pretty wellâ¦ The easiest way to start is probably take the latest version of Moose. Open the example browser and look for OpenStreetMap Integration. Thierry, although pretty cool, I have the impression the integration could be better. Here is a wish list: - Tile caching - Predictive zoom level. E.g., If I click twice on the zoomin button, it is likely that I will click a third time. So preloading the needed tile would be good Again Thierry and Onil, thanks for this working piece of work. This is fantastic! Cheers, Alexandre > On Jul 16, 2015, at 7:51 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 16/07/2015 03:59, Hilaire a Ã©crit : >> Hi Thierry, >> >> This is what I did, I pick up latest Moose, and play a bit. It is nice >> indeed. >> >> A few remarks >> - loading the tiles is slow, does it comes from me? I am right on the >> local tile server in Hsinchu.. I am not sure the right tile server is >> used. a.tile.openstreetmap.org > > Do you need a dedicated tile server or the generic ones? We had an issue trying to accelerate tile loading when improving that part during PharoDays. > > I'll have a look at Moose to see which version of Roassal you are dealing with. > >> - the graphic quality is not optimal, blurred > > RTOSM interpolates between tiles zoom levels to gives you more freedom when zooming; this may comes with a slightly degraded image quality. Unless it is heavily blurred in which case it is something else. A screenshot? > >> - I have a hard time to find live programming (in fact I failed): trying >> to get on an inspector was not obvious, then I don't know what I can do >> to modify the model and its view > > This is more a Moose problem then. > >> - one RTOSM example fails because of fuel version > > There is a problem with the version of Roassal you are using. I remember correcting that a while ago. > >> - examples #exampleSeismOnEarthLive #exampleSeismOnEarthLiveZoom fail also. > > Yes, the links used to download the data (from the usgs if I remember correctly) have changed recently; there was a discussion on the mailing list not long ago (on pharo-dev or moose-dev); I don't know in which version of Roassal this was corrected. > > Thierry > >> >> Thanks for the tips >> >> Hilaire >> >> Le 16/07/2015 02:28, Thierry Goubier a Ã©crit : >>> Hi Hilaire, >>> >>> OSM tiles support was added to Roassal, and demonstrated in two videos >>> [1][2]. The context of the work was presented at FOSDEM [3]. >>> >>> In the pillarhub document, I demonstrated how to query the raw OSM >>> data; we made sure that the tile support and georeferenced data could >>> go on the same level, and be precise to the pixel to the underlying >>> tile rendering. >>> >>> I'm sure all this works in Pharo4, just try the RTOSM examples! There >>> is probably a way to make it interactive with data downloading and a >>> playground, using the sample code present in the pillarhub document. >>> >>> [2] is a bit different, it uses a sensor network design tool and >>> simulateur which requires VisualWorks, Occam and/or a Cuda GPU :). But >>> it makes for an interesting demo / talk if it is your field, just >>> contact Onil. >>> >>> Thierry >>> >>> [1] https://www.youtube.com/watch?v=6zoGIsQaGUo >>> [2] https://www.youtube.com/watch?v=sMB7DG-lbiU >>> [3] https://archive.fosdem.org/2015/schedule/event/cirela/ >>> >>> >>> Le 15/07/2015 19:16, Hilaire a Ã©crit : >>>> Hi, >>>> >>>> In a few weeks I will give a speech in Taiwan at NCHC[1] about Pharo, my >>>> intend is to present release 4. I already did speeches there in the past >>>> about Pharo, but I have a hard time to raise interest to the point >>>> people want to jump in. >>>> But I hope to have an angle this time because NCHC recently offers a >>>> server and the hosting for an openstreetmap tile server (the first in >>>> Asia by the way), and there is high interest here in Taiwan about OSM >>>> related stuff. >>>> >>>> I read here, job has been done with Roassal and OSM, but it is not clear >>>> for me how to get in using OSM within Pharo. I am particularly >>>> interested in providing an interactive demo where live programming shows >>>> its value. >>>> >>>> I have found these pointers bellow. I am interested by any additional >>>> tips and url, and particularly the compatibility with Pharo4. >>>> >>>> https://github.com/fstephany/OSMMaps >>>> http://pillarhub.pharocloud.com/hub/ThierryGoubier/5y08m9uu71o8i7a35ijwr766p >>>> >>>> >>>> >>>> >>>> Thanks >>>> >>>> Hilaire >>>> >>>> >>>> [1] >>>> https://en.wikipedia.org/wiki/National_Center_for_High-Performance_Computing >>>> >>>> >>> >>> >>> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 16, 2015

Re: [Pharo-users] Openstreetmap on Pharo

by Hilaire

Le 16/07/2015 13:51, Thierry Goubier a Ã©crit : > > Do you need a dedicated tile server or the generic ones? We had an > issue trying to accelerate tile loading when improving that part > during PharoDays. I am wondering if the used server is the geographically closest one. Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

July 16, 2015