Direct Connection Support for Oracle Spatial Database?

[mganji7799]

Hi Martin Team and Community,

First off, thank you for developing martin, it looks like a very promising vector tile server.

We are currently working with a large Oracle database that contains a significant volume of spatial/geometric data (using Oracle Spatial features, likely SDO_GEOMETRY). For our development team's needs, we require an efficient way to serve this vector data as map tiles (vector tiles).

We've been evaluating martin for this purpose. However, based on our research and review of the documentation, it seems that martin primarily supports PostGIS as a direct database source. We couldn't find explicit confirmation or instructions on whether it's possible to connect martin directly to an Oracle database to serve tiles from its spatial tables.

Our core question is: Does martin currently support a direct connection to an Oracle database as a data source for generating vector tiles?

We understand that one workaround could be migrating or replicating the data to PostGIS, but given the scale and existing infrastructure, a direct connection to Oracle would be highly preferable for us.

Could you please confirm if:

1. Direct Oracle Spatial connection is currently supported?
2. If not, are there any plans or ongoing work to add Oracle support in the future?
3. Are there any known alternative approaches or best practices for using martin with data originating from Oracle Spatial, other than full data migration?
   We appreciate any information or clarification you can provide on this topic.

Thanks for your time and effort on this great project!

Best regards,

[CommanderStorm]

Direct Oracle Spatial connection is currently supported?

No, we currently support:

• pmtiles
• mbtiles
• postgres

We (more specifically @sharkAndshark ) is currently working on COG-support.

If not, are there any ongoing work to add Oracle support in the future?

Not to my knowledge

If not, are there any plans to add Oracle support in the future?

I don't plan to pay money for a db-licence just to develop for Oracle.
Other maintainer/contributors plans may be different and then we could add support.

Are there any known alternative approaches or best practices for using martin with data originating from Oracle Spatial, other than full data migration?
We appreciate any information or clarification you can provide on this topic.

Oracle does provide mapviewer server according to their docs.
Oracle does not list the licencing cost for this component.
You will have to figure this out with your sales representative at oracle.

Honestly: is sticking with oracle worth the licencing cost? Would changing to posgis not be simpler?

[CommanderStorm]

@pka (or the corp. he works for) does do consulting around this area if oracles tileserver is lacking.
https://bbox.earth/ is feature wise on the same level as martin.

You can likely convince them (with money) to add oracle support.
Given what you would be paying for Oracle, this might be a good deal ^^

[CommanderStorm]

here is an article discussing how to solve this "the oracle way".

https://medium.com/@kpatenge/how-to-create-vector-tiles-from-spatial-data-managed-in-the-oracle-database-db662f2b5544

Here is an talk talking about migrating away from big oracle ^^
https://www.youtube.com/watch?v=enoswavd9_0

Potentially (because I know they do great work and if you need excellent performance) https://cedardb.com/ might also be possible.
Not ideal though likely given the lacking geospatial support

[nyurik]

@mganji7799 thx for the question. To add to what @CommanderStorm said above - you are more than welcome to use Martin as a library, and simply add support for another backend (Oracle) to it. Maintaining Oracle support would add significant burden to this unpaid project, so I don't think we would want to support it in this repo.

That said, if there is a significant interest in this, we could further refactor Martin's code to make it easier to build additional proprietary backends, or to simplify using Martin as a library even further -- and that could be a valuable addition.

One significant limitation of a plugin architecture with Rust is that Rust ABI is not stable. Which means we would have to rely on C interface to communicate with the .so / .dll / .dynlib files, making it less than ideal. Using Martin as a lib is easier, but that means only one wrapper can exist at a time (which might be ok).

[CommanderStorm]

I'd like to not maintain out of tree plugins or a plugin architecture to start.
In-tree or nothing.

If @mganji7799 would take on the maintenance on this part, this would be fine by me.
Same as @sharkAndshark does COG-maintenance ❤️ ^^

I know that oracle on node does not have (good) client libraries avaliable.
https://github.com/kubo/rust-oracle/tree/master is not acceptable, I don't want ODPI-C as a RUNtime dependency.
But as a cfg(feature = "oracle") I would be fine with it, as long as

• the code we ship does not enable said feature
• code and documentation are better or equivalent to the postgres version
• test coverage is high

As said above, I will not invest time into fixing issues with oracle.
My oppinion of them is tarnished by the stability issues TUMs production oracle deployment has and how insanely much money we spend on this.

[nyurik]

@CommanderStorm I didn't say we would maintain anything out-of-tree. Rather, we may (eventually) offer a good plugin architecture into Martin for the 3rd parties to add any kind of backends they may want. Plugins is a difficult topic, especially in Rust, so this would not happen any time soon. Martin as lib is a better short term path, but again - the actual wrapper over Martin would be maintained by the author of that wrapper, not core Martin maintainers.