For GIS applications

rubyonrails-talk
1

Sijo Kg wrote:

Hi    Could anybody please which is the most widely used gem for GIS applications I came across http://ym4r.rubyforge.org/ym4r-doc/     But seen it has not been updated since 2006

Thanks in adavnce Sijo

Are you interested in drawing maps, dealing with geocoded data, or what? There are different gems out there for different parts of the problem domain.

Best,

2

Hi

Yes I want to draw maps, dealing with geocoded data, As exacltly according to the latlong information have to draw routes on map etc So could you please suggest a good gem and also the other helper urls if any

Sijo

3

Sijo Kg wrote:

Hi

Yes I want to draw maps, dealing with geocoded data,

I've been using YM4R for that. I've only dealt with Google Maps, but I understand that Mapstraction is very helpful if you're dealing with multiple mapping services.

As exacltly according to the latlong information have to draw routes on map etc

I don't know if there's anything out there to help with drawing routes.

So could you please suggest a good gem and also the other helper urls if any

Take a look at GeoRuby and Spatial Adapter as well.

Also, on the database side, I recommnd using PostgreSQL with PostGIS.

Sijo

Best,

4

Sijo Kg wrote:

Hi

Yes I want to draw maps, dealing with geocoded data,

I've been using YM4R for that. I've only dealt with Google Maps, but I understand that Mapstraction is very helpful if you're dealing with multiple mapping services.

I would vote for using Mapstraction as it isolates you from a particular map provider. I have a problem with YM4R however. The concept there is to construct the map object in the controller and then display it in the view. I suggest that the map is not an object to be set up in the controller but is a feature of the view. I setup the data to be viewed in the controller/model (@markers to hold the markers for example) and then construct the map in the view just using the mapstraction (or google) js API. I believe this fits the MVC architecture better.

Colin

5

Colin Law wrote: [...]

I have a problem with YM4R however. The concept there is to construct the map object in the controller and then display it in the view.

It's been a while since I've touched that part of my codebase, so I had temporarily forgotten that.

I'm actually no longer quite using YM4R's view code in any case, since it puts JavaScript in the HTML files, which is poor practice.

I suggest that the map is not an object to be set up in the controller but is a feature of the view.

I suggest that you're probably wrong. If the map is to be treated as an object at all (admittedly, that's a nontrivial if), then the controller is by definition the appropriate place to load it.

I setup the data to be viewed in the controller/model (@markers to hold the markers for example) and then construct the map in the view just using the mapstraction (or google) js API. I believe this fits the MVC architecture better.

This is more or less what I do as well, but whether it's a better use of MVC or not depends on whether you consider the map or the markers to be the primary objects.

Colin

Best,

6

Colin Law wrote: [...]

I have a problem with YM4R however. The concept there is to construct the map object in the controller and then display it in the view.

It's been a while since I've touched that part of my codebase, so I had temporarily forgotten that.

I'm actually no longer quite using YM4R's view code in any case, since it puts JavaScript in the HTML files, which is poor practice.

I suggest that the map is not an object to be set up in the controller but is a feature of the view.

I suggest that you're probably wrong. If the map is to be treated as an object at all (admittedly, that's a nontrivial if), then the controller is by definition the appropriate place to load it.

I am suggesting that the map is not to be treated as an object any more than a table is in a view. It is just a particular way of viewing a set of markers, waypoints etc. If you want a table in a view one does not setup number of columns, column width, styles etc in the controller then display it in the view so why setup the map object in the controller? Just setup the waypoints or whatever is required there and display the map in the view. Another reason for this approach is the same controller could be used to serve the data as xml, or as a tabular view or any other view.

I setup the data to be viewed in the controller/model (@markers to hold the markers for example) and then construct the map in the view just using the mapstraction (or google) js API. I believe this fits the MVC architecture better.

This is more or less what I do as well, but whether it's a better use of MVC or not depends on whether you consider the map or the markers to be the primary objects.

Arguably, almost by definition of what a map is, a map is a view on a dataset, not a primary object. If it were, then the map would be stored in the db, rather than the definition of what one would like to see on the view.

I agree though that if one does consider the map to be a primary object then setting it up in the controller may be a valid approach.

Not that I think one should be dogmatic about this sort of thing, the best way to do something is often the way that sits best with ones gut feelings for how to partition a problem, rather than that demanded by some ideological truth.

Colin

7

Colin Law wrote: [...]

I am suggesting that the map is not to be treated as an object any more than a table is in a view. It is just a particular way of viewing a set of markers, waypoints etc.

Yes, that was sort of what I had in mind when I was talking about markers being primary.

[...]

Another reason for this approach is the same controller could be used to serve the data as xml, or as a tabular view or any other view.

That's an excellent point.

Best,