MapInfo provider

[Jackie Ng]

Hi All,

Something that's been brewing in the back of my mind is whether it is feasible to write an FDO provider for MapInfo.

Now the reason I say feasible is because:

a) The OGR provider already supports MapInfo files. I could be duplicating effort here, but then again this could be a SHP or PostGIS situation where OGR can support it, but there is already a specialized provider for it.

b) The only libraries I know of that can read/write MapInfo file are MITAB and OGR, but reading more about MITAB I find that its is based on the OGR library, so this is going back to point a)

We have a lot of potential clients (MapInfo users) here in Australia, where a dedicated MapInfo FDO provider could really sway them over. Having to work with the lowest common denominator behaviour of the OGR provider is kind of cumbersome though.

I guess my question is: Is it worth writing a MapInfo-only FDO provider when the OGR provider already exists that can adequately serve this purpose?

- Jackie

[zspitzer]

what about a lightweight wrapper around the existing ogr provider?

On Thu, Mar 26, 2009 at 1:11 AM, Jackie Ng <[hidden email]> wrote:

>
> Hi All,
>
> Something that's been brewing in the back of my mind is whether it is feasible to write an FDO provider for MapInfo.
>
> Now the reason I say feasible is because:
>
> a) The OGR provider already supports MapInfo files. I could be duplicating effort here, but then again this could be a SHP or PostGIS situation where OGR can support it, but there is already a specialized provider for it.
>
> b) The only libraries I know of that can read/write MapInfo file are MITAB and OGR, but reading more about MITAB I find that its is based on the OGR library, so this is going back to point a)
>
> We have a lot of potential clients (MapInfo users) here in Australia, where a dedicated MapInfo FDO provider could really sway them over. Having to work with the lowest common denominator behaviour of the OGR provider is kind of cumbersome though.
>
> I guess my question is: Is it worth writing a MapInfo-only FDO provider when the OGR provider already exists that can adequately serve this purpose?
>
> - Jackie
> --
> View this message in context: http://n2.nabble.com/MapInfo-provider-tp2532574p2532574.html
> Sent from the FDO Users mailing list archive at Nabble.com.
>
> _______________________________________________
> fdo-users mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-users
>

--
Zac Spitzer -
http://zacster.blogspot.com
[phone]
_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

[Traian Stanev]

Hi Jackie,

What MapInfo features that can be provided by FDO are hidden by OGR? How important are they?

Seems like the answers to those questions would help determine whether it's worth writing a dedicated provider.

I know that Autodesk has successfully used the OGR provider with Map3D for certain customers (also in Australia).


Traian


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jackie Ng
Sent: Wednesday, March 25, 2009 10:11 AM
To: [hidden email]
Subject: [fdo-users] MapInfo provider


Hi All,

Something that's been brewing in the back of my mind is whether it is feasible to write an FDO provider for MapInfo.

Now the reason I say feasible is because:

a) The OGR provider already supports MapInfo files. I could be duplicating effort here, but then again this could be a SHP or PostGIS situation where OGR can support it, but there is already a specialized provider for it.

b) The only libraries I know of that can read/write MapInfo file are MITAB and OGR, but reading more about MITAB I find that its is based on the OGR library, so this is going back to point a)

We have a lot of potential clients (MapInfo users) here in Australia, where a dedicated MapInfo FDO provider could really sway them over. Having to work with the lowest common denominator behaviour of the OGR provider is kind of cumbersome though.

I guess my question is: Is it worth writing a MapInfo-only FDO provider when the OGR provider already exists that can adequately serve this purpose?

- Jackie
--
View this message in context: http://n2.nabble.com/MapInfo-provider-tp2532574p2532574.html
Sent from the FDO Users mailing list archive at Nabble.com.

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users
_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

[Kenneth Skovhede, GEOGRAF A/S]

That depends on what you want to accomplish.

I find that speed is very good, even better than SDF when using TAB files.
All the data I have tested with renders fine, but date/time columns are
not supported.

But, the OGR only supports a geometry and a single logical expression.
It would be cool to have it support arbitrary FDO expressions.
If that is your target, I belive some of the other providers have much
of the logic for this,
and that it would be a better solution than a pure MI provider.

For now TAB files are read-only, because OGR/MITAB does not support it,
but at least some
work has been done in this regards:
http://bugzilla.maptools.org/show_bug.cgi?id=1859

Regards, Kenneth Skovhede, GEOGRAF A/S



Jackie Ng skrev:

> Hi All,
>
> Something that's been brewing in the back of my mind is whether it is feasible to write an FDO provider for MapInfo.
>
> Now the reason I say feasible is because:
>
> a) The OGR provider already supports MapInfo files. I could be duplicating effort here, but then again this could be a SHP or PostGIS situation where OGR can support it, but there is already a specialized provider for it.
>
> b) The only libraries I know of that can read/write MapInfo file are MITAB and OGR, but reading more about MITAB I find that its is based on the OGR library, so this is going back to point a)
>
> We have a lot of potential clients (MapInfo users) here in Australia, where a dedicated MapInfo FDO provider could really sway them over. Having to work with the lowest common denominator behaviour of the OGR provider is kind of cumbersome though.
>
> I guess my question is: Is it worth writing a MapInfo-only FDO provider when the OGR provider already exists that can adequately serve this purpose?
>
> - Jackie
>  

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

[Frank Warmerdam]

On Wed, Mar 25, 2009 at 10:49 AM, Kenneth Skovhede, GEOGRAF A/S
<[hidden email]> wrote:
> That depends on what you want to accomplish.
>
> I find that speed is very good, even better than SDF when using TAB files.
> All the data I have tested with renders fine, but date/time columns are not
> supported.

Folks,

I do believe that date/time support has been incorporated into MITAB and
the OGR bindings in recent versions of OGR.  If not it might be worth
filing a ticket on this.  Does the OGR FDO provider support date/time fields?
They are a relatively recent addition to OGR.

> But, the OGR only supports a geometry and a single logical expression.
> It would be cool to have it support arbitrary FDO expressions.
> If that is your target, I belive some of the other providers have much of
> the logic for this,
> and that it would be a better solution than a pure MI provider.

Is this an improvement that can be done right in the FDO OGR provider?

Overall, I'd prefer to see the requirement for good mapinfo support drive
improvements to the FDO OGR provider (and perhaps OGR/MITAB)
rather than do something really custom.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent
_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

[Traian Stanev]

Hi Frank,

DateTime support is implemented in the OGR FDO provider, but not tested, so maybe it has bugs.

FDO expression support can be implemented in the provider as well.

Traian


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Frank Warmerdam (External)
Sent: Wednesday, March 25, 2009 12:02 PM
To: FDO Users Mail List
Subject: Re: [fdo-users] MapInfo provider

On Wed, Mar 25, 2009 at 10:49 AM, Kenneth Skovhede, GEOGRAF A/S
<[hidden email]> wrote:
> That depends on what you want to accomplish.
>
> I find that speed is very good, even better than SDF when using TAB files.
> All the data I have tested with renders fine, but date/time columns are not
> supported.

Folks,

I do believe that date/time support has been incorporated into MITAB and
the OGR bindings in recent versions of OGR.  If not it might be worth
filing a ticket on this.  Does the OGR FDO provider support date/time fields?
They are a relatively recent addition to OGR.

> But, the OGR only supports a geometry and a single logical expression.
> It would be cool to have it support arbitrary FDO expressions.
> If that is your target, I belive some of the other providers have much of
> the logic for this,
> and that it would be a better solution than a pure MI provider.

Is this an improvement that can be done right in the FDO OGR provider?

Overall, I'd prefer to see the requirement for good mapinfo support drive
improvements to the FDO OGR provider (and perhaps OGR/MITAB)
rather than do something really custom.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent
_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users
_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

[Jackie Ng]

I did notice some DateTime-related breakage when the GDAL/OGR library was upgraded to 1.6

http://trac.osgeo.org/fdo/ticket/447

- Jackie

Traian Stanev wrote:

Hi Frank,

DateTime support is implemented in the OGR FDO provider, but not tested, so maybe it has bugs.

FDO expression support can be implemented in the provider as well.

Traian


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Frank Warmerdam (External)
Sent: Wednesday, March 25, 2009 12:02 PM
To: FDO Users Mail List
Subject: Re: [fdo-users] MapInfo provider

On Wed, Mar 25, 2009 at 10:49 AM, Kenneth Skovhede, GEOGRAF A/S
<[e-mail]> wrote:
> That depends on what you want to accomplish.
>
> I find that speed is very good, even better than SDF when using TAB files.
> All the data I have tested with renders fine, but date/time columns are not
> supported.

Folks,

I do believe that date/time support has been incorporated into MITAB and
the OGR bindings in recent versions of OGR.  If not it might be worth
filing a ticket on this.  Does the OGR FDO provider support date/time fields?
They are a relatively recent addition to OGR.

> But, the OGR only supports a geometry and a single logical expression.
> It would be cool to have it support arbitrary FDO expressions.
> If that is your target, I belive some of the other providers have much of
> the logic for this,
> and that it would be a better solution than a pure MI provider.

Is this an improvement that can be done right in the FDO OGR provider?

Overall, I'd prefer to see the requirement for good mapinfo support drive
improvements to the FDO OGR provider (and perhaps OGR/MITAB)
rather than do something really custom.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [e-mail]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent
_______________________________________________
fdo-users mailing list
[e-mail]
http://lists.osgeo.org/mailman/listinfo/fdo-users
_______________________________________________
fdo-users mailing list
[e-mail]
http://lists.osgeo.org/mailman/listinfo/fdo-users

[Kenneth Skovhede, GEOGRAF A/S]

Some javascript/style in this post has been disabled (why?)

Frank Warmerdam skrev:

On Wed, Mar 25, 2009 at 10:49 AM, Kenneth Skovhede, GEOGRAF A/S
[hidden email] wrote:
  

That depends on what you want to accomplish.

I find that speed is very good, even better than SDF when using TAB files.
All the data I have tested with renders fine, but date/time columns are not
supported.
    

Folks,

I do believe that date/time support has been incorporated into MITAB and
the OGR bindings in recent versions of OGR.  If not it might be worth
filing a ticket on this.  Does the OGR FDO provider support date/time fields?
They are a relatively recent addition to OGR.

  

I'm using GDAL 1.4, so date/time columns might work with a more recent OGR/GDAL version.

But, the OGR only supports a geometry and a single logical expression.
It would be cool to have it support arbitrary FDO expressions.
If that is your target, I belive some of the other providers have much of
the logic for this,
and that it would be a better solution than a pure MI provider.
    

Is this an improvement that can be done right in the FDO OGR provider?

  

Yes, to simplify the development, the FDO OGR provider does not parse full FDO statements, but
looks for a statement tree like: "<geom filter> AND <logical expr>" and supports either side missing
or swapped, but nothing else.

I have wanted to build full support for FDO expressions, but have not had the time or FDO knowledge to do so yet.

Overall, I'd prefer to see the requirement for good mapinfo support drive
improvements to the FDO OGR provider (and perhaps OGR/MITAB)
rather than do something really custom.
  

I support that idea.

Best regards,
  

--
Regards, Kenneth Skovhede, GEOGRAF A/S


_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

[Traian Stanev]

Quoting:
==
"Yes, to simplify the development, the FDO OGR provider does not parse full FDO statements, but
looks for a statement tree like: "<geom filter> AND <logical expr>" and supports either side missing
or swapped, but nothing else.

I have wanted to build full support for FDO expressions, but have not had the time or FDO knowledge to do so yet."
==

Yes this is true, I initially did this since those were the only queries one would reasonably expect from Map3D or MapGuide. I think we can improve this by taking the query translator from the SQLite provider. It extracts any geometric or ID queries from the filter and converts the remainder to an SQL statement to pass on to SQLite. In the OGR case we can pass the remainder SQL to OGR. The SQL translator code is a bit incomplete, and in the case of OGR would have to be slightly different, but the general idea would be the same.


Traian



________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Kenneth Skovhede, GEOGRAF A/S [[hidden email]]
Sent: Thursday, March 26, 2009 5:55 AM
To: FDO Users Mail List
Subject: Re: [fdo-users] MapInfo provider

Frank Warmerdam skrev:

On Wed, Mar 25, 2009 at 10:49 AM, Kenneth Skovhede, GEOGRAF A/S
<[hidden email]><mailto:[hidden email]> wrote:


That depends on what you want to accomplish.

I find that speed is very good, even better than SDF when using TAB files.
All the data I have tested with renders fine, but date/time columns are not
supported.



Folks,

I do believe that date/time support has been incorporated into MITAB and
the OGR bindings in recent versions of OGR.  If not it might be worth
filing a ticket on this.  Does the OGR FDO provider support date/time fields?
They are a relatively recent addition to OGR.



I'm using GDAL 1.4, so date/time columns might work with a more recent OGR/GDAL version.

But, the OGR only supports a geometry and a single logical expression.
It would be cool to have it support arbitrary FDO expressions.
If that is your target, I belive some of the other providers have much of
the logic for this,
and that it would be a better solution than a pure MI provider.



Is this an improvement that can be done right in the FDO OGR provider?



Yes, to simplify the development, the FDO OGR provider does not parse full FDO statements, but
looks for a statement tree like: "<geom filter> AND <logical expr>" and supports either side missing
or swapped, but nothing else.

I have wanted to build full support for FDO expressions, but have not had the time or FDO knowledge to do so yet.

Overall, I'd prefer to see the requirement for good mapinfo support drive
improvements to the FDO OGR provider (and perhaps OGR/MITAB)
rather than do something really custom.


I support that idea.


Best regards,


--
Regards, Kenneth Skovhede, GEOGRAF A/S

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users