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

gis implementation (opengis) [CORE659] #1025

Open
firebird-automations opened this issue Jul 21, 2004 · 23 comments
Open

gis implementation (opengis) [CORE659] #1025

firebird-automations opened this issue Jul 21, 2004 · 23 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: kohan_gg (kohan_gg)

Is duplicated by CORE1768
Is duplicated by CORE2690

Votes: 28

SFID: 995200#⁠
Submitted By: kohan_gg

Implementation of spatial operator (cf. opengis
consortium) will be very very useful
For example Postgres and Mysql had already yet implemented.
Do you think that it's possible in near future ?

@firebird-automations
Copy link
Collaborator Author

Commented by: Alice F. Bird (firebirds)

Date: 2006-01-17 14:55
Sender: dimitr
Logged In: YES
user_id=61270

I doubt anyone would be interested even in not so near
future. Those needing proper GIS support are always with
PostgreSQL.

@firebird-automations
Copy link
Collaborator Author

Commented by: Eron Lloyd (elloyd)

I think FB having this would be awesome. Could it be developed as an add-on, like PostGIS?

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Palmer (asp86)

If Firebird where "spatially enabled", which would allow it to be used as a backend spatial database for geographic information systems (GIS), it could potentially blow other products like ESRI's SDE or Oracle's Spatial extension or PostGIS out of the water.

Please see OpenGIS "Simple Features Specification For SQL" (http://www.opengis.org/docs/99-049.pdf) for details.

@firebird-automations
Copy link
Collaborator Author

Commented by: Godofredo Contreras Nava (frdcn)

I have been a firebird user for more than 5 years, also I have been working with spatial databases since then and one feature I have ever wished is spatial extension for firebird. I have developed a small udf to transform wkt to wkb and store them in a blob field, also I have been contributing to some opensource gis and there are libraries that could help to implement the extension in an easy way, libraries to manage spatial indexes, libraries to transform between wkt and wkb, and also spatial analisys libraries.

It will be really nice to have a small and fast relational database server as firebird with a spatial extension.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 10683 ] => Firebird [ 15058 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue is duplicated by CORE1768 [ CORE1768 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Dehorter Olivier (dehorter)

more and more often, data needs to integrate information from GPS. thus inclusion of GIS module into the firebird project could be a major progress

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue is duplicated by CORE2690 [ CORE2690 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Simon Greener (sgreener)

It is interesting to note, for those who know or have heard of ESRI's ArcSDE, that the very first version - 1.0 - was originally released on Interbase. The coordinates were stored in an array of integers. I enjoyed using it and achieved some amazing things with it. The original version was developed by Geomatic Technologies Incorporates (GTI), Bellingham, WA. It was sold to ESRI Inc (Redlands, Ca) who then ported it to Oracle etc and dropped the Interbase version.

It would be rather just for Firebird to have spatial. Even SQLite has it!

@firebird-automations
Copy link
Collaborator Author

Commented by: vander clock stephane (arkadia)

what the status of this ? for exemple even Sqlite3 (http://www.sqlite.org/rtree.html) support it :(
it's could be very usefull

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

Are you willing to sponsor the development? ;-)

@firebird-automations
Copy link
Collaborator Author

Commented by: Christian Waldmann (swissknife)

Hello Dmitry

Do you have an estimate for complexity and work to do (days, weeks,...) of adding the new index kind RTREE, keeping in mind the others may follow (HASH, GIST,...)?

@firebird-automations
Copy link
Collaborator Author

Commented by: vander clock stephane (arkadia)

Hello Dmitry

same as Christan, Do you have an estimate for complexity and work to do (days, weeks,...) of adding the new index kind RTREE ?

the code can be freely study from sqlite3 (it's a very ligh SQL engine that support RTREE pretty wheel) for exemple...

Thanks
stéphane

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

No, I don't (at the moment). I could try to research the requirements during the Christmas holidays though.

@firebird-automations
Copy link
Collaborator Author

Commented by: vander clock stephane (arkadia)

could be good to do a blog about the project to know how many people are ready to sponsor it ?
with me it's already 1, but i hope i will be not alone ?

stephane

@firebird-automations
Copy link
Collaborator Author

Commented by: Simon Greener (sgreener)

I don't know much about the inner workings of Firebird. Here are some things I see that need examining.

1. How easily the indexing system can be extended to support RTrees?
The RTree, in and of itself, is not difficult to implement.
There are a number of open source implementations around that can provide code/examples.

2. The maturity of the type system of the host database. Most implementations around at the
moment are all single inherited so only offer a single type "geometry" (and/or "geography"
for geodetic). Few offer the full type system of the OGC/SQLMM standard such that one can
declare a table to have a column of type "point" that therefore doesn't have a method area.
Depending on the type system an implementation that uses "dot" notation referencing is
possible (polygon.Area()) with some, cf PostGIS, only supporting functional approaches
eg Area(polygon).

3. Functions. The SQL/MM standard provides the required list of functions across a range of separate areas.
Implementation of what is known as Simple Features is the basic minimum for vector data. PostGIS provides
a large range of additional, non standard, operations that are there because the standard should have them
but don't!

4. Operators and query optimisation. How extensible is the database's query optimiser for efficient plan generation?

5. Aggregate operators.

6. Metadata integration (fairly straightforwards).

I am happy to be involved on some sort of guidance/testing role. I am a database person and not really a full on professional
developer. My only development experience is with Java as the lead for GeoRaptor.

I am a single person consulting business so while I can affor some time to work on this for free I cannot do much more unless
some sort of financial incentive was available.

regards
Simon
http://www.spatialdbadvisor.com

@firebird-automations
Copy link
Collaborator Author

Commented by: Juergen Seelmann (joggi)

Quite a while since the last entry. I am working with TatukGIS storing data in FB: So slow compared to the use of SHP Files. This is an issue which gets more and more urgent: Any news?

@firebird-automations
Copy link
Collaborator Author

Commented by: Juergen Seelmann (joggi)

Sorry, I send a bit fast yesterday: Can we take up this BLOG proposal: To gather all those who would support/sponsor the issue?
I wouldn't like to use a 'slow' database such as PostGre/PostGIS just for 'fast' GIS...

@firebird-automations
Copy link
Collaborator Author

Commented by: Peter Borissow (peter.borissow)

I know its been several years since this ticket was opened but I too would love to see this feature implemented in Firebird. Why? Because there are very few options out there for an embedded database with spatial support. Sure, there's SQLite and Spatialite but SQLite has some significant concurrency issues that drives me nuts.

From a user perspective, I see 4 basic requirements for a spatial extension for Firebird:

(1) Support for spatial data types (point, lines, polygons, etc)

(2) Support for spatial operators (intersects, within, touches, etc)

(3) Support for projected and geodetic coordinates

(4) Spatial indexing (e.g. RTree)

Open source projects like GEOS and PROJ4 provide many of the building blocks for this. And of course, there is the Spatialite extension for SQLite. In fact, if it were up to me, I would see if there's some way to bootstrap Spatialite into Firebird.

I'm not a C/C++ developer so I can't really contribute much to this endeavor. I would be willing to make a small financial contribution to this task if that's what it would take to get this going. I don't have much to donate but maybe enough to buy a couple cases of beer or coffee or whatever :-) Perhaps others would be willing to contribute as well?

@firebird-automations
Copy link
Collaborator Author

Commented by: Juergen Seelmann (joggi)

End of February 2014. Firebird 3.0 is upcoming with strong support for Python... Python is commonly used in the GIS environment. Still nobody supporting the spatial extension in a way as outlined by Peter Borissow/Simon Greener.

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

I think, tracker is not a good place to discuss such thing as sponsorship of developing of a new feature.
Better start discussion in fb-general or contact with Firebird Foundation.

@ldesousa
Copy link

Hi there. Are there any developments regarding SQLMM support? Thank you.

@romansimakov
Copy link
Collaborator

Hi Luis! In Red Soft we do some steps in this direction. If you have ideas, usecases, etc it would be nice to keep in touch. Feel free to contact me.

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

No branches or pull requests

3 participants