For GIS applications

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,

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

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,

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

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,

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

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,