Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GeoJSON #66

Closed
marcelino-m opened this issue Nov 10, 2016 · 8 comments
Closed

GeoJSON #66

marcelino-m opened this issue Nov 10, 2016 · 8 comments

Comments

@marcelino-m
Copy link
Contributor

marcelino-m commented Nov 10, 2016

I plan to implement versions of some functions to get GeoJSON
What do you think about it?

@brendannee
Copy link
Member

Great idea. I'd live to have that implemented.

What functions do you think should return geojson?

@marcelino-m
Copy link
Contributor Author

I think it makes sense for the following functions:

  • getStops
  • getStopsByRoute
  • getStopsByDistance
  • getShapesByRoute

Maybe the name could be something like funcNameAsGeoJson?

@brendannee
Copy link
Member

Sounds good. Or, instead we could extend those functions to take an
additional optional parameter 'geojson' which can be true or false. Or it
could be called 'type' and take the argument 'geojson'.

What do you think?
On Sat, Nov 12, 2016 at 10:26 Marcelo Muñoz Araya notifications@github.com
wrote:

I think it makes sense for the following functions:

  • getStops
  • getStopsByRoute
  • getStopsByDistance
  • getShapesByRoute

Maybe the name could be something like funcName_AsGeoJson_?


You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#66 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAF32SpERyxTVTLCP3n_4Lbm8E-9Ldd1ks5q9YZegaJpZM4KuUuq
.

@marcelino-m
Copy link
Contributor Author

Ok! I agree, Let's try it that way.

2016-11-12 13:27 GMT-03:00 Brendan Nee notifications@github.com:

Sounds good. Or, instead we could extend those functions to take an
additional optional parameter 'geojson' which can be true or false. Or it
could be called 'type' and take the argument 'geojson'.

What do you think?
On Sat, Nov 12, 2016 at 10:26 Marcelo Muñoz Araya <
notifications@github.com>
wrote:

I think it makes sense for the following functions:

  • getStops
  • getStopsByRoute
  • getStopsByDistance
  • getShapesByRoute

Maybe the name could be something like funcName_AsGeoJson_?


You are receiving this because you commented.

Reply to this email directly, view it on GitHub
<https://github.com/brendannee/node-gtfs/issues/
66#issuecomment-260111637>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAF32SpERyxTVTLCP3n_
4Lbm8E-9Ldd1ks5q9YZegaJpZM4KuUuq>
.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#66 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJuaz1NGEY1jMAzQkzSNZ4tKzs9j4HM5ks5q9ekFgaJpZM4KuUuq
.

@Sashenka
Copy link

Hello, I'm kind of new at this so bear with me. I was also interested in an option to get an output in geoJSON. I added a geoJSON parameter which can be true or false (or anything really since I check only if it is there) which transform the result in a FeatureCollection of Points for getStops, getStopsByRoute and getStopsByDistance. You can look at it in my fork: ecaf6cd

I am not really satisfied on how I introduced the new parameter, since it is optional and there are other optional parameters I had to take into account that it can take the place of the other optional parameter. You already had some code for this case but only if there is only one optional parameter. It works but feels hacky. I would also maybe pass an options object just in case there are other optional parameters added down the line. To keep backward compatibility the optional parameters that still exist would have to stay outside the option object though.

Anyways, this is what I did so far. I'll start working on other functions like routes and maybe also try to tackle streams, this would be a nice addition though and I've been wanting to try them for a while.

@brendannee
Copy link
Member

I like your idea of passing an options object to support other optional parameters, and for functions that already take optional parameters we could move these in. That would be part of a entirely new version of this library with breaking changes.

@brendannee
Copy link
Member

I added some new routes to node-gtfs that are geoJSON specific. This ended up working better than adding options to the existing methods.

I added routes for getting stops and shapes from GTFS.

I also published a new package called gtfs-to-geojson that uses these routes in a handy command line tool to generate geoJSON and save it to a file.

https://github.com/brendannee/gtfs-to-geojson

Check it out and let me know what you think.

@Sashenka
Copy link

New routes might be the better idea here to keep backward compatibility. The options object idea would be better off for a new version, as it is now it creates more problem than it solves.

Thanks by the way, this is nice work. I'm learning as I fiddle with your code :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants