Upcoming changes in I/O formats structure

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Upcoming changes in I/O formats structure

Mateusz Loskot
Administrator
Folks,

Lately, I have discussed with Barend and Bruno proposal to change
structure of I/O formats. The motivation is to make it clear and simple,
but fairly well-structure at the same time.

I have applied necessary changes in my working copy and
I would like to commit it soon.
So, this message is a pre-commit announcement and warning.

Basically, changes I/O formats structure include:
1) Get rid of domain or format standardisation body, so structure is flattened.
2) Introduce some basic convention for naming files/folders per format layout.
3) Separate I/O formats for simple geometries from multi-geometries

The new layout layout looks like this:

geometry/io/<FORMAT>/<FORMAT>.hpp  (unsure, see note [1] below)
geometry/io/<FORMAT>/read.hpp
geometry/io/<FORMAT>/write.hpp
geometry/io/<FORMAT>/iomanip.hpp (see note [2])
geometry/io/<FORMAT>/detail/...  (.hpp files with private
implementation details)

Note [1] Boost.Geometry stores all-in-one headers inside related
folder, for example
boost/geometry/geometries/geometries.hpp
but not at one level above:
boost/geometry/geometries.hpp
Most/many Boost libraries use the latter convention
So, I'm not sure if all-in-one headers for formats should be:
geometry/io/<FORMAT>/<FORMAT>.hpp
or
geometry/io/<FORMAT>.hpp
For now, I keep it geometry/io/<FORMAT>/<FORMAT>.hpp


Note [2] the iomanip.hpp used to be named stream_<FORMAT>.hpp.
If present, the stream_<FORMAT>.hpp defines stream manipulators for format.
I renamed it to iomanip.hpp to follow std naming of <iomanip> what is
more self-descriptive and exactly indicates purpose of the header.


Similar layout will be used for I/O for multi-geometries:
geometry/multi/io/<FORMAT>/...

Similar layout will be also used for I/O extensions:
boost/geometry/extensions/io/<FORMAT>/...
boost/geometry/extensions/multi/io/<FORMAT>/...


So, for example, the new structure will be:

boost/geometry/io/dsv/
boost/geometry/io/wkt
boost/geometry/multi/io/dsv//
boost/geometry/multi/io/wkt/

Finally, we have planned to move two formats from extensions to the
set of released formats:
- SVG
- WKT

The OGC WKT (Well-Known-Text) format is a simple and popular
GIS-derived format, however it has no GIS-specific
features built-in, so it is a perfect general purpose format for 2D
geometries (and soon 3D too).
The WKT format has complete implementation, so it is a mature piece of software.
We already use WKT format in tests, so it is a required piece of our kit.

The SVG is a popular format and it is extremely useful as it is the
only format so far which
we can use for visualisations of Boost.Geometry objects.

Next, I'm going to complete implementation of OGC WKB
(Well-Known-Binary) format and
move it to default set. The WKB format is a binary equivalent of WKT format

To summary, in near future I would like to have the following set of
formats released as built-in:

boost/geometry/io/dsv/
boost/geometry/io/svg/
boost/geometry/io/wkb/
boost/geometry/io/wkt/


If there are any objections or suggestions of improvements, please speak now.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
_______________________________________________
ggl mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/ggl
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming changes in I/O formats structure

Barend
Hi Mateusz,

Thanks for your proposal. I agree with it, only a few remarks.

First one for the users: as long as you include things like
"boost/geometry.hpp", nothing will change. Only if you are specifying
headerfiles explicitly (don't think many will do), there might be some
changes necessary.

Second, WKT was already included in the Release, from the beginning on.
We cannot do without (it is indeed in nearly all unit tests). It
currently resides in/boost/geometry/domains/gis/io/wkt. The files in
extensions are still there (think they can be removed now indeed) but
they contain a compiler-warning to indicate the move.




On 7-12-2011 23:45, Mateusz Łoskot wrote:

> Note [1] Boost.Geometry stores all-in-one headers inside related
> folder, for example
> boost/geometry/geometries/geometries.hpp
> but not at one level above:
> boost/geometry/geometries.hpp
> Most/many Boost libraries use the latter convention
> So, I'm not sure if all-in-one headers for formats should be:
> geometry/io/<FORMAT>/<FORMAT>.hpp
> or
> geometry/io/<FORMAT>.hpp
> For now, I keep it geometry/io/<FORMAT>/<FORMAT>.hpp

Well spotted. I'm not against harmonizing with most Boost libraries.

>
> Note [2] the iomanip.hpp used to be named stream_<FORMAT>.hpp.
> If present, the stream_<FORMAT>.hpp defines stream manipulators for format.
> I renamed it to iomanip.hpp to follow std naming of<iomanip>  what is
> more self-descriptive and exactly indicates purpose of the header.

OK for me.


> Finally, we have planned to move two formats from extensions to the
> set of released formats:
> - SVG
>
> The SVG is a popular format and it is extremely useful as it is the
> only format so far which we can use for visualisations of Boost.Geometry objects.

I do agree, Boost.Geometry's SVG mapper is simple but powerful. Let's
get it into Release as well.


>
> Next, I'm going to complete implementation of OGC WKB
> (Well-Known-Binary) format and
> move it to default set.

Great! Good news.

Regards, Barend

_______________________________________________
ggl mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/ggl
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming changes in I/O formats structure

Mateusz Loskot
Administrator
Hi Barend,

On 10 December 2011 14:31, Barend Gehrels <[hidden email]> wrote:
> Thanks for your proposal. I agree with it, only a few remarks.
>
> First one for the users: as long as you include things like
> "boost/geometry.hpp", nothing will change. Only if you are specifying
> headerfiles explicitly (don't think many will do), there might be some
> changes necessary.

I'm not sure I understand.
Currently, boost/geometry.hpp includes this:

#include <boost/geometry/domains/gis/io/wkt/wkt.hpp>

as well as other IO headers:

#include <boost/geometry/io/dsv/write.hpp>

So, I aimed to replace them with single:

#include <boost/geometry/io/io.hpp>

which would include all released IO formats:

#include <boost/geometry/io/dsv/dsv.hpp>
#include <boost/geometry/io/wkt/wkt.hpp>

What shall I do?

> Second, WKT was already included in the Release, from the beginning on. We
> cannot do without (it is indeed in nearly all unit tests). It currently
> resides in/boost/geometry/domains/gis/io/wkt.

Yes.

> The files in extensions are still there (think they can be removed now indeed)
> but they contain a compiler-warning to indicate the move.

Yes, and I actually aimed to remove these deprecated header
before folks will start using it widely :)

Please, correct me wherever I'm wrong.

Cheers,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
_______________________________________________
ggl mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/ggl
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming changes in I/O formats structure

Mateusz Loskot
Administrator
In reply to this post by Mateusz Loskot
2011/12/7 Mateusz Łoskot <[hidden email]>:
> Folks,
>
> Lately, I have discussed with Barend and Bruno proposal to change
> structure of I/O formats. The motivation is to make it clear and simple,
> but fairly well-structure at the same time.
>
> I have applied necessary changes in my working copy and
> I would like to commit it soon.

I have just committed first big stage of the changes discussed in this thread.
I'm still reviewing tests and examples, so there may be some things broken
temporarily. There are a few more changes to come.
I am completing this task tomorrow, so bear with me.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
_______________________________________________
ggl mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/ggl
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming changes in I/O formats structure

Bruno Lalande
Hi Mateusz,

Not sure if this is part of the things "broken temporarily" or if you missed it so I prefer to warn. I have the following error when trying to run the tests:

error: Unable to find file or target named
error:     'domains/'
error: referred from project at
error:     '.'

For now I'm working around it by just removing the line in the Jamfile.

Regards
Bruno


_______________________________________________
ggl mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/ggl
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming changes in I/O formats structure

Mateusz Loskot
Administrator
On 16 December 2011 11:11, Bruno Lalande <[hidden email]> wrote:

> Hi Mateusz,
>
> Not sure if this is part of the things "broken temporarily" or if you missed
> it so I prefer to warn. I have the following error when trying to run the
> tests:
>
> error: Unable to find file or target named
> error:     'domains/'
> error: referred from project at
> error:     '.'
>
> For now I'm working around it by just removing the line in the Jamfile.

Bruno,

Thanks for the report. Indeed, it was one of the issues.
Now fixed.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
_______________________________________________
ggl mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/ggl
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Re: [ggl] Upcoming changes in I/O formats structure

Guillaume Carbonneau
In reply to this post by Mateusz Loskot
Hello, 

I was wondering what was the status of this refactoring. I'd be interested in using the wkb reader/writer.

I'm looking here but I don't see it:
http://svn.boost.org/svn/boost/trunk/boost/geometry/io/

Thanks

On Wednesday, December 7, 2011 at 2:45 PM, Mateusz Łoskot wrote:

Folks,

Lately, I have discussed with Barend and Bruno proposal to change
structure of I/O formats. The motivation is to make it clear and simple,
but fairly well-structure at the same time.

I have applied necessary changes in my working copy and
I would like to commit it soon.
So, this message is a pre-commit announcement and warning.

Basically, changes I/O formats structure include:
1) Get rid of domain or format standardisation body, so structure is flattened.
2) Introduce some basic convention for naming files/folders per format layout.
3) Separate I/O formats for simple geometries from multi-geometries

The new layout layout looks like this:

geometry/io/<FORMAT>/<FORMAT>.hpp (unsure, see note [1] below)
geometry/io/<FORMAT>/read.hpp
geometry/io/<FORMAT>/write.hpp
geometry/io/<FORMAT>/iomanip.hpp (see note [2])
geometry/io/<FORMAT>/detail/... (.hpp files with private
implementation details)

Note [1] Boost.Geometry stores all-in-one headers inside related
folder, for example
boost/geometry/geometries/geometries.hpp
but not at one level above:
boost/geometry/geometries.hpp
Most/many Boost libraries use the latter convention
So, I'm not sure if all-in-one headers for formats should be:
geometry/io/<FORMAT>/<FORMAT>.hpp
or
geometry/io/<FORMAT>.hpp
For now, I keep it geometry/io/<FORMAT>/<FORMAT>.hpp


Note [2] the iomanip.hpp used to be named stream_<FORMAT>.hpp.
If present, the stream_<FORMAT>.hpp defines stream manipulators for format.
I renamed it to iomanip.hpp to follow std naming of <iomanip> what is
more self-descriptive and exactly indicates purpose of the header.


Similar layout will be used for I/O for multi-geometries:
geometry/multi/io/<FORMAT>/...

Similar layout will be also used for I/O extensions:
boost/geometry/extensions/io/<FORMAT>/...
boost/geometry/extensions/multi/io/<FORMAT>/...


So, for example, the new structure will be:

boost/geometry/io/dsv/
boost/geometry/io/wkt
boost/geometry/multi/io/dsv//
boost/geometry/multi/io/wkt/

Finally, we have planned to move two formats from extensions to the
set of released formats:
- SVG
- WKT

The OGC WKT (Well-Known-Text) format is a simple and popular
GIS-derived format, however it has no GIS-specific
features built-in, so it is a perfect general purpose format for 2D
geometries (and soon 3D too).
The WKT format has complete implementation, so it is a mature piece of software.
We already use WKT format in tests, so it is a required piece of our kit.

The SVG is a popular format and it is extremely useful as it is the
only format so far which
we can use for visualisations of Boost.Geometry objects.

Next, I'm going to complete implementation of OGC WKB
(Well-Known-Binary) format and
move it to default set. The WKB format is a binary equivalent of WKT format

To summary, in near future I would like to have the following set of
formats released as built-in:

boost/geometry/io/dsv/
boost/geometry/io/svg/
boost/geometry/io/wkb/
boost/geometry/io/wkt/


If there are any objections or suggestions of improvements, please speak now.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
_______________________________________________
ggl mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/ggl


_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: [ggl] Upcoming changes in I/O formats structure

Guillaume Carbonneau
This seems to include some of the support but does not support multi-*

Is there a branch that includes multi-* support?

On Monday, April 30, 2012 at 10:50 PM, Guillaume Carbonneau wrote:

Hello, 

I was wondering what was the status of this refactoring. I'd be interested in using the wkb reader/writer.

I'm looking here but I don't see it:

Thanks

On Wednesday, December 7, 2011 at 2:45 PM, Mateusz Łoskot wrote:

Folks,

Lately, I have discussed with Barend and Bruno proposal to change
structure of I/O formats. The motivation is to make it clear and simple,
but fairly well-structure at the same time.

I have applied necessary changes in my working copy and
I would like to commit it soon.
So, this message is a pre-commit announcement and warning.

Basically, changes I/O formats structure include:
1) Get rid of domain or format standardisation body, so structure is flattened.
2) Introduce some basic convention for naming files/folders per format layout.
3) Separate I/O formats for simple geometries from multi-geometries

The new layout layout looks like this:

geometry/io/<FORMAT>/<FORMAT>.hpp (unsure, see note [1] below)
geometry/io/<FORMAT>/read.hpp
geometry/io/<FORMAT>/write.hpp
geometry/io/<FORMAT>/iomanip.hpp (see note [2])
geometry/io/<FORMAT>/detail/... (.hpp files with private
implementation details)

Note [1] Boost.Geometry stores all-in-one headers inside related
folder, for example
boost/geometry/geometries/geometries.hpp
but not at one level above:
boost/geometry/geometries.hpp
Most/many Boost libraries use the latter convention
So, I'm not sure if all-in-one headers for formats should be:
geometry/io/<FORMAT>/<FORMAT>.hpp
or
geometry/io/<FORMAT>.hpp
For now, I keep it geometry/io/<FORMAT>/<FORMAT>.hpp


Note [2] the iomanip.hpp used to be named stream_<FORMAT>.hpp.
If present, the stream_<FORMAT>.hpp defines stream manipulators for format.
I renamed it to iomanip.hpp to follow std naming of <iomanip> what is
more self-descriptive and exactly indicates purpose of the header.


Similar layout will be used for I/O for multi-geometries:
geometry/multi/io/<FORMAT>/...

Similar layout will be also used for I/O extensions:
boost/geometry/extensions/io/<FORMAT>/...
boost/geometry/extensions/multi/io/<FORMAT>/...


So, for example, the new structure will be:

boost/geometry/io/dsv/
boost/geometry/io/wkt
boost/geometry/multi/io/dsv//
boost/geometry/multi/io/wkt/

Finally, we have planned to move two formats from extensions to the
set of released formats:
- SVG
- WKT

The OGC WKT (Well-Known-Text) format is a simple and popular
GIS-derived format, however it has no GIS-specific
features built-in, so it is a perfect general purpose format for 2D
geometries (and soon 3D too).
The WKT format has complete implementation, so it is a mature piece of software.
We already use WKT format in tests, so it is a required piece of our kit.

The SVG is a popular format and it is extremely useful as it is the
only format so far which
we can use for visualisations of Boost.Geometry objects.

Next, I'm going to complete implementation of OGC WKB
(Well-Known-Binary) format and
move it to default set. The WKB format is a binary equivalent of WKT format

To summary, in near future I would like to have the following set of
formats released as built-in:

boost/geometry/io/dsv/
boost/geometry/io/svg/
boost/geometry/io/wkb/
boost/geometry/io/wkt/


If there are any objections or suggestions of improvements, please speak now.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
_______________________________________________
ggl mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/ggl



_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: [ggl] Upcoming changes in I/O formats structure

Mateusz Loskot
Administrator
On 1 May 2012 16:52, Guillaume Carbonneau
<[hidden email]> wrote:
> This seems to include some of the support but does not support multi-*
> http://svn.boost.org/svn/boost/trunk/boost/geometry/extensions/gis/io/wkb/

Guillaume,

This refactoring and restructurisation had been postponed due to Boost
1.49 release
and eventually hasn't been completed. I hope to complete it within
next 1-2 weeks.

> Is there a branch that includes multi-* support?

There is no support for multi-geometries in io/wkb yet.
I am hoping to add it within next weeks too.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
--
Mateusz Loskot
http://mateusz.loskot.net