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
GIS Data types #456
Comments
Hi @lselvy, to answer your question in part, unfortunately there is no hard documentation for the plugin architecture used by node-orm2 - that being said, there are a number of plugins out there including node-orm-transaction, node-orm-mysql-fts and node-orm-timestamps which should give you the tools you need to get started. Please feel free to ask questions if you get lost, I know the codebase can be a bit daunting for those unfamiliar with its various intricacies, and we'll try and help out wherever we can. |
Ok, so the answer is to roll up a new project for GIS enabled node-orm? Just wanted to know if we should natively support it. |
I think integrating the functionality into the core is something @dresende would need to decide on, but there are really no disadvantages to anybody in using the plugin framework as it will allow people who want the functionality to easily integrate it while ensuring that the codebases remain separate for maintenance purposes. |
I also use GIS in some projects, but I think many don't need it, so my opinion is to choose one this paths:
I'm inclined to path 2 but if you have a different opinion or another path feel free to share. |
I also wonder how much of this can already be done via custom properties. |
Given that custom properties should be used to implement the GIS data types, should we consider having them part of the core set? In the long run I can go either way and have been brushing up on the plugin architecture so that I can add the appropriate data types and allow for JS querying. I think it would round out node-orm very nicely. I only know PostGIS, so the first implementation would be for PostGIS, but I could teach myself the other DBs GIS capabilities. I think I am going to start with a plugin and see how far I can get. I will list the repo for it here after I have something working. I would agree with dresende's point above. If we are talking a full featured implementation we should think plugin. If that means a change to the plugin architecture I'll report back on it. |
Plugin sounds good 👍 |
I'm trying to do just that, but i'm stuck at building a custom select expression for the geometry column, something like |
Uggh
a kitten is dying each time i spawn the app |
Poor kittens :( With that in mind & once 375 is done, what would the PostGIS plugin need to do beyond defining PostGIS property types? |
Now that #488 is merged, it should be possible to create a custom type which will automatically add Specifically: datastoreGet: function (prop, helper) {
return helper.escape('ST_AsGeoJSON(??)', [prop.mapsTo]);
}
// "SELECT `abc`, `def`, (ST_AsGeoJSON(ghi)) AS `ghi` FROM `table`" |
Now an obvious missing piece is the ability to define custom indexes types.
|
I would recommend writing the SQL for that by hand. If using the migrations library this is as easy as executing the required SQL in a migration. I'm a bit unwilling to add suport for this as it's postgres specific. One would need to implement this in an DB agnostic manner. |
I'm already doing this (i'll see if it's easier with node-migrate-orm2) with sql statements (no animal is hurt this time), and figured there was some kind of consistency in defining an index as bound to a type. |
I am working on an application that is geospatially enabled, and am using PostGIS to do it (for those that don't know PostGIS is a GIS library for the PostgreSQL database).
I see that no work has currently been put into GIS data types and models, and in other programming languages (like python), usually GIS data types and support are left for other modules.
I pose this question, should the inclusion of GIS data types (point, line, polygon, multiline, multipoint, multipolygon, etc ect) and the resulting function (ST_Contains, ST_Within, ST_Centroid, etc) be included as part of node-orm2, or should it be relegated to its own package?
If it is its own package, can someone point me to the plugin architecture for node-orm2?
The text was updated successfully, but these errors were encountered: