Hi all I already answered in a different thread, but again here:
+1 for b) it should be mandatory Regards > Am 08.06.2016 um 17:46 schrieb FRANCISCO XAVIER SUMBA TORAL > <[email protected]>: > > Hi, > > Definitely, the new release can’t wait too long. Besides, for a PostgreSQL > user install PostGIS is feasible, but I don’t discard the option that in the > future GeoSPARL could be pluggable. It will be like a packet manager. It not > just helps GeoSPARQL module but also other modules > that will appear in the future. > > So, I choose second option. > b) +1 > > Cheers. > > >> On Jun 8, 2016, at 10:20, fernando baculima <[email protected]> wrote: >> >> Hi all. >> >> I think it should be mandatory. >> >> For users who want to use PostgreSQL, somehow, it wouldn't be complicated >> to install extensions like PostGIS. >> >> For those who use the default database (H2) or other, I guess there won´t >> be any trouble >> >> >> >> Cheers >> >> 2016-06-08 3:02 GMT-05:00 Sergio Fernández <[email protected]>: >> >>> So, summarizing, we have two options: >>> >>> 1) Spend some more time (hard to estimate) to get GeoSPARQL optional >>> >>> 2) Forget it and make it mandatory >>> >>> >>> >>> On Wed, Jun 8, 2016 at 10:00 AM, Sergio Fernández <[email protected]> >>> wrote: >>> >>>> Hi, >>>> >>>> TL;DR optional GeoSPARQL support is so dirty to implement, so I want to >>>> discuss what to do. >>>> >>>> as the last part to have GeoSPARQL in KiWi (MARMOTTA-584[1][2]) merged >>>> into develop, in the last days I've been approaching (fighting) to make >>> the >>>> need of PostGIS option {MARMOTTA-638 [3]) and try to finally work on a >>> new >>>> release with this feature. >>>> >>>> As discussed [4], the advantage of getting MARMOTTA-638 done would be to >>>> lower the update requirements (i.e., if you don't want GeoSPARQL you >>> would >>>> not need to have PostGIS extension installed in PostgreSQL). >>>> >>>> The disadvantage is that complicates quite some the implementation: as we >>>> extensively use prepare statements you would need to have two db schemas >>>> (one with a fake geometry, another one with an actual geometry), which >>>> complicates everything. Locally I have a path I'm very unsatisfied with >>> its >>>> quality, and I'm pretty sure will be the source of many issues in the >>> near >>>> future. Therefore I; m not completely sure I want to continue that path, >>>> but I think it's an aspect that requires further discussion. >>>> >>>> So, summarizing, we have two options: >>>> >>>> 1) Spend some more time (hard to estimate) to get GeoSPARQL optional >>>> >>>> 2) Forget >>>> >>>> My vote now goes to the second option, because: a) it make the source >>> base >>>> far more maintainable; b) after all PostGIS is widely supported and >>> trivial >>>> to install; and c) this feature is blocking 3.4.0 for too long. But I'd >>>> like to listen to the opinion of the community to really decide what to >>> do. >>>> What do you think, guys? >>>> >>>> Thanks for your time. >>>> >>>> Cheers, >>>> >>>> [1] https://issues.apache.org/jira/browse/MARMOTTA-584 >>>> [2] https://github.com/apache/marmotta/tree/MARMOTTA-584 >>>> [3] https://issues.apache.org/jira/browse/MARMOTTA-638 >>>> [4] http://markmail.org/message/3u55tk4xe4g2qgoa >>>> >>>> >>>> -- >>>> Sergio Fernández >>>> Partner Technology Manager >>>> Redlink GmbH >>>> m: +43 6602747925 >>>> e: [email protected] >>>> w: http://redlink.co >>>> >>> >>> >>> >>> -- >>> Sergio Fernández >>> Partner Technology Manager >>> Redlink GmbH >>> m: +43 6602747925 >>> e: [email protected] >>> w: http://redlink.co >>> >
