Nabble - PostGIS - Dev

Re: [PostGIS] #273: ST_GeomFromGML crashes in Windows compiled in MingW

2009-12-10T15:14:24Z

#273: ST_GeomFromGML crashes in Windows compiled in MingW
----------------------+-----------------------------------------------------
Reporter: robe | Owner: colivier
Type: defect | Status: new
Priority: medium | Milestone: PostGIS 1.5.0
Component: postgis | Version: trunk
Resolution: | Keywords:
----------------------+-----------------------------------------------------
Comment (by pramsey):

I'll do (1) when I get home. On (2) it just popped out that way, following
the Windows Build instructions on the Wiki.

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/273#comment:33>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

Re: [PostGIS] #273: ST_GeomFromGML crashes in Windows compiled in MingW

2009-12-10T14:40:46Z

#273: ST_GeomFromGML crashes in Windows compiled in MingW
----------------------+-----------------------------------------------------
Reporter: robe | Owner: colivier
Type: defect | Status: new
Priority: medium | Milestone: PostGIS 1.5.0
Component: postgis | Version: trunk
Resolution: | Keywords:
----------------------+-----------------------------------------------------
Comment (by colivier):

Yeap i'm pleased ;)

And now two questions:

1) Could you try with removing lwfree from is_gml_namespace function
(about line 170)

2) Did you have to do something special under MinGW to have a dynamic
library flavour ?

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/273#comment:32>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[wktraster] WKT Raster Documentation

2009-12-10T11:11:29Z

Hi,

I have converted the doc I wrote (a while ago) about WKT Raster in the wiki:

http://trac.osgeo.org/postgis/wiki/WKTRaster/Documentation01

More is to come about each function but this is the base skeleton.

Your comment/revision/corrections are welcomes...

We expect to have the first beta release next summer.

Thanks,

Pierre

_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

Re: [PostGIS] #273: ST_GeomFromGML crashes in Windows compiled in MingW

2009-12-10T10:30:02Z

#273: ST_GeomFromGML crashes in Windows compiled in MingW
----------------------+-----------------------------------------------------
Reporter: robe | Owner: colivier
Type: defect | Status: new
Priority: medium | Milestone: PostGIS 1.5.0
Component: postgis | Version: trunk
Resolution: | Keywords:
----------------------+-----------------------------------------------------
Comment (by pramsey):

You'll be pleased (?) to know that I can duplicate this in my MinGW build
too. I tried removing the free at lwgeom_in_gml.c:623 (see the attached
patch) but it still crashes. I don't have a debug version built yet, so I
have no meaningful stack trace. I'm going to rebuild, but it'll take
pretty much all day, due to slowness of MinGW + VM.

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/273#comment:31>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

Re: [PostGIS] #332: WKT geometry tag match and mismatch

2009-12-10T08:07:08Z

Re: [PostGIS] #332: WKT geometry tag match and mismatch

2009-12-10T07:54:37Z

[PostGIS] #345: Syntax error in postgis_restore.pl

2009-12-10T07:54:18Z

#345: Syntax error in postgis_restore.pl
----------------------+-----------------------------------------------------
Reporter: patrickh | Owner: pramsey
Type: defect | Status: new
Priority: medium | Milestone: PostGIS 1.5.0
Component: postgis | Version: trunk
Keywords: |
----------------------+-----------------------------------------------------
Line 47 of `postgis_restore.pl` on the trunk has an extra double quote (")
character in it that a parse error when executing the script. This was
introduced in r4746. The current line is:

{{{
#!perl
(@ARGV >= 3) || die "Usage: postgis_restore.pl <postgis.sql> <db> <dump>
["<createdb_options>]\nRestore a custom dump (pg_dump -Fc) of a postgis
enabled database.\n";
}}}

It should be the following:

{{{
#!perl
(@ARGV >= 3) || die "Usage: postgis_restore.pl <postgis.sql> <db> <dump>
[<createdb_options>]\nRestore a custom dump (pg_dump -Fc) of a postgis
enabled database.\n";
}}}

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/345>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

Re: [PostGIS] #343: History Table Enhancements

2009-12-10T07:34:21Z

#343: History Table Enhancements
----------------------+-----------------------------------------------------
Reporter: pimpaa | Owner: pimpaa
Type: patch | Status: new
Priority: medium | Milestone: PostGIS 1.5.0
Component: postgis | Version: 1.4
Resolution: | Keywords: History Tables
----------------------+-----------------------------------------------------
Comment (by pimpaa):

Thanks for your opinion mcayland.

But there is some code which already is in trunk. It´s lightweight and can
deal with spatial information.

This is not a versioning scenario, just a historic of changes.

Have you tried the module?

Do you have any suggestions to enhance the module to work better with
specifics of spatial information?

Thanks for your opinion :)

Replying to [comment:1 mcayland]:
> I think this is an interesting application, however I think that what
you're tackling here is a more generic database versioning problem rather
than a spatial-specific problem. If you search the PostgreSQL mailing list
archives for "time travel", you'll find lots of information on this, plus
several related projects on pgfoundry.org which you may find have already
solved this particular problem.
>
>
> HTH,
>
> Mark.

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/343#comment:2>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

Re: [PostGIS] #332: WKT geometry tag match and mismatch

2009-12-10T06:01:09Z

#332: WKT geometry tag match and mismatch
----------------------+-----------------------------------------------------
Reporter: mloskot | Owner: pramsey
Type: defect | Status: new
Priority: medium | Milestone: PostGIS 1.5.0
Component: postgis | Version: trunk
Resolution: | Keywords:
----------------------+-----------------------------------------------------
Comment (by robe):

Mark,

I disagree with you on this point and mostly your train of thought rather
than we should or shouldn't keep this. Well I don't think we should keep
this as Paul refer's to it "Anal retentive check" now that I have heard
your argument.

The reason being. The spec details the minimum that we should support.
So any valid geometry we need to support with what we claim to be
compliant :).

However the spec doesn't say anything about extending said support and
databases do it all the time -- hell we are guilty of it in a number of
functions. For example we go way beyond what the spec says we should
support with ST_PointOnSurface and ST_Centroid (I discovered this when
trying to figure out why the hell can't I do yeh in IBM and SQL Server and
eh certainly not Oracle because, well they decided to not go further than
what the spec dictated in yeh or neh or stick (I think Oracle stuck to the
letter on those 2)).

The spec says nothing about support ST_Union for aggregates -- I don't
think ST_Union is defined for aggregates and we even state that in our
docs, and sure many spatial dbs decided that was hmm stupid.

So my general argument -- as long as we can support at least the minimum
of what the spec says is valid, we are okay and its our liberty to go
beyond that. IBM for one in all their examples I believe has propercase
and all their examples show that. -- so I think its a no-brainer that we
have to fix this to support all types of cases people who haven't
discovered the cap lock may use or if they are just used to typing in a
different case. That is clearly a bug and while we are fixing it, we
might as well make our code shorter and easier to maintain.

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/332#comment:7>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

Re: [PostGIS] #343: History Table Enhancements

2009-12-10T02:36:37Z

#343: History Table Enhancements
----------------------+-----------------------------------------------------
Reporter: pimpaa | Owner: pimpaa
Type: patch | Status: new
Priority: medium | Milestone: PostGIS 1.5.0
Component: postgis | Version: 1.4
Resolution: | Keywords: History Tables
----------------------+-----------------------------------------------------
Comment (by mcayland):

I think this is an interesting application, however I think that what
you're tackling here is a more generic database versioning problem rather
than a spatial-specific problem. If you search the PostgreSQL mailing list
archives for "time travel", you'll find lots of information on this, plus
several related projects on pgfoundry.org which you may find have already
solved this particular problem.

HTH,

Mark.

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/343#comment:1>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

Re: [PostGIS] #332: WKT geometry tag match and mismatch

2009-12-10T02:35:06Z

Re: 1.5 iconv dependency

2009-12-10T02:33:09Z

Paul Ramsey wrote:

> Sounds good to me. Most of our dependencies are either too useful
> (geos, proj) or too common (xml, iconv) to have as optionals.
>
> P.

Yeah; especially since it's likely XML will become core functionality in
the future, it's nice to get people used to requiring it to build :)

Regina/Olivier: did you managed to resolve the dynamic linking problem
under Windows in the end?

ATB,

Mark.

--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

Re: [PostGIS] #332: WKT geometry tag match and mismatch

2009-12-10T02:29:55Z

Re: [PostGIS] #222: GUI compile under MinGW

2009-12-10T02:07:46Z

#222: GUI compile under MinGW
----------------------+-----------------------------------------------------
Reporter: pramsey | Owner: mcayland
Type: defect | Status: new
Priority: medium | Milestone: PostGIS 1.4.2
Component: postgis | Version: 1.4.X
Resolution: | Keywords:
----------------------+-----------------------------------------------------
Comment (by mcayland):

Okay thanks for sorting this out - I'll merge into the new shp2pgsql stuff
when it's done :)

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/222#comment:21>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

Re: [PostGIS] #332: WKT geometry tag match and mismatch

2009-12-09T15:57:10Z

Re: [PostGIS] #332: WKT geometry tag match and mismatch

2009-12-09T15:38:30Z

Re: [PostGIS] #332: WKT geometry tag match and mismatch

2009-12-09T10:12:45Z

Re: [PostGIS] #332: WKT geometry tag match and mismatch

2009-12-09T08:33:05Z

[PostGIS] #344: Libxml2 become mandatory

2009-12-09T07:48:07Z

#344: Libxml2 become mandatory
----------------------+-----------------------------------------------------
Reporter: colivier | Owner: colivier
Type: task | Status: new
Priority: medium | Milestone: PostGIS 1.5.0
Component: postgis | Version:
Keywords: |
----------------------+-----------------------------------------------------
Modify configure step, remove HAVE_LIBXML2 stuff, updpate doc

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/344>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

Re: 1.5 iconv dependency

2009-12-09T07:42:08Z

Sounds good to me. Most of our dependencies are either too useful
(geos, proj) or too common (xml, iconv) to have as optionals.

P.

On Wed, Dec 9, 2009 at 5:58 AM, Mark Cave-Ayland
<mark.cave-ayland@...> wrote:

> Hi folks,
>
> Going over the loader code, it struck me that we can simplify things a bit
> by removing all of the #ifdef HAVE_ICONV ... #endif blocks. We already
> detect libiconv in configure.ac as we need to find the linker flags; I'm
> just wondering why we don't just make it a compulsary dependency in order to
> keep builds more consistent across the board?
>
>
> ATB,
>
> Mark.
>
> --
> Mark Cave-Ayland - Senior Technical Architect
> PostgreSQL - PostGIS
> Sirius Corporation plc - control through freedom
> http://www.siriusit.co.uk
> t: +44 870 608 0063
>
> Sirius Labs: http://www.siriusit.co.uk/labs
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>

_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

1.5 iconv dependency

2009-12-09T05:58:51Z

Hi folks,

Going over the loader code, it struck me that we can simplify things a
bit by removing all of the #ifdef HAVE_ICONV ... #endif blocks. We
already detect libiconv in configure.ac as we need to find the linker
flags; I'm just wondering why we don't just make it a compulsary
dependency in order to keep builds more consistent across the board?

ATB,

Mark.

--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[PostGIS] #343: History Table Enhancements

2009-12-09T03:48:43Z

#343: History Table Enhancements
----------------------------+-----------------------------------------------
Reporter: pimpaa | Owner: pimpaa
Type: patch | Status: new
Priority: medium | Milestone: PostGIS 1.5.0
Component: postgis | Version: 1.4
Keywords: History Tables |
----------------------------+-----------------------------------------------
I'm here to propose some enhancements I had in my mind for my History
Tables implementation.

I have some interesting ideas for complementary functions inside this
"module".

a) a function that allows the user to deactivates the logging of a certain
table. All this function does is to delete the specified table rules and
clean-up geometry_columns and history_information tables with relevant
with information.

a.1) a function that allows the user to activate the logging in history
tables again. the function will be the same as the used to initially start
the log. the only difference is that now uses a simple exists() test to
determine if table already exists, and if so, recreate the rules and all
the necessary rows in history_information and geometry_columns.

these two functions are already ready and in the following patch.

b) a function to populate a new history table with all records in the
table currently being logged. this should not be hard, but can be
cumbersome for large datasets. I appreciate any thoughts on this matter.

Any other requests for patches or enhancements, please, post it here and
i'll try my best.

As always, I appreciate any comments or critics.

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/343>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

Re: Distance Madness

2009-12-09T01:23:48Z

I think I was complicating things way to much last week.

Some car trips later I think like this :-)

keep all structures and treebuilding. first do a deepdive in the tree (or climbing maybe), for each level check which child is closest to the other geometries center of bbox.

The distance between the leafes found that way should give a good first mindistance. In many cases the right answer will be found already here. But to find out we have to do it all from the beginning like it works now, but with a better mindistance to start with.

I realise I should have tested to order all vertexes from "distance to corresponding center of bbox" in my algoritm instead of what I'm doing now. It would have been nicer code. I don't know if it would have been faster and I don't know if I then could find when I was done. But I havenæt considered the possibility.

This tree of yours Paul, should work great with 3D too, shouldn't it?

Just making the nodes representing boxes instead of surfaces.

/Nicklas

2009-12-02 Nicklas Avén wrote:

The car trip to work gave me some more rounds of thinking. >

The idea have to be developed. It shouldn't matter how many childen we find optimal.

The thing is to find the best way of storing which one of the children that represents maxX, maxY and so on, so we can do the right diving.

It shouldn't cost anything extra (almost), the information is there in rect_node_internal_new(), we just have to store it.

/Nicklas

2009-12-02 Nicklas Avén wrote:
>
> Yes, I see what you mean. I thought about it too. >

> >

But what about mixing all ideas in one.

> >

I think I maybe was struck by an idea about it this morning, worth considering.

> >

What about giving every parent 4 children. And then in the optimal node have one child with maxX, one with maxY, one minX and one minY. Probably it will be the same child that in reality has two or more positions, but then identify that it is the same and force the fourth child to that place, so the place for , say maxX is hold by a child with no internal max or min value (good enough)

> >

Then to get a overall direction between the geometries, compare the center of the boundingboxes and decide if the direction falls under nort, south, west or east.

> >

So for two geometries that is west and east of each other we start deepdiving in the west respectively east corner of the nodes all the way domn to the leaf and get a first fairly good mindistance very fast. Then we can do the rest with a better min distance to sort away the ones too far away for considering.

> >

Does it make any sense?

> >

I'm in a hurrry so maybe not to structured.

> >

/Nicklas
> >
> > 2009-12-01 Paul Ramsey wrote:
> >
> > I'm thinking that the worst-case behavior of the tree traversal could
> > >also be a lot worse than the worse case behavior of the sort solution
> > >(the recursion seems to provide a depth-first search, and if the first
> > >stab is fairly far from the closest distance, it could take a while to
> > >prune back the tree towards the optimum). Getting the most out of the
> > >tree is almost certainly going to require caching.
> > >
> > >P.
> > >
> > >On Tue, Dec 1, 2009 at 11:12 AM, Nicklas Avén
> > > .aven@...> wrote:
> > >> Yes, I think you are right that my mistake was to use malloc.
> > >> /Nicklas
> > >>
> > >> 2009-12-01 Paul Ramsey wrote:
> > >>
> > >> Nick,
> > >>>
> > >>>You asked if maybe you did something naive and the answer is "possibly
> > >>>yes". For example, if you did your allocations using malloc() you got
> > >>>a much more expensive heap allocation than if you used palloc() (or
> > >>>lwalloc() in the context of a pgsql build).
> > >>>
> > >>>But anyhow, yes, knowing the number of edges before-hand, and knowing
> > >>>our tree building scheme, we could easily allocate the whole segment
> > >>>in one go at the start (~1.5 * npoints * sizeof(node)).
> > >>>
> > >>>For 2.0, I've been thinking about the way to make this stuff "real",
> > >>>and I'm pretty sure the answer is to stick an extra handle on
> > >>>POINTARRAY for holding these optional structures. Then, an
> > >>>lwgeom_index(LWGEOM *g) function would walk into an LWGEOM, ensure all
> > >>>the *bbox pointers are filled in, and build the trees on all the
> > >>>POINTARRAYs. Then the whole thing could be neatly cached, if
> > >>>necessary, etc.
> > >>>
> > >>>P.
> > >>>
> > >>>On Tue, Dec 1, 2009 at 10:16 AM, Nicklas Avén
> > >>> wrote:
> > >>>> aul
> > >>>> If it is as I suspect that the number of memory allocations is the most
> > >>>> costly part of this, wouldn't it be possible to allocate all of it once
> > >>>> and
> > >>>> for all. If you allocate one list of nodes for each level, the whole
> > >>>> structure of the tree is given. You know where the children and parents
> > >>>> is
> > >>>> related to the start of the "level lists" the only thing missing is the
> > >>>> min
> > >>>> and max x any y for each level.
> > >>>>
> > >>>> /Nicklas
> > >>>>
> > >>>> 2009-12-01 Nicklas Avén wrote:
> > >>>>
> > >>>> :-) >
> > >>>>
> > >>>>
> > >>>>>
> > >>>> I think I see what you are doing
> > >>>>>
> > >>>> Had to take another look...
> > >>>>>
> > >>>>
> > >>>>>
> > >>>> The comarasion part is the same as I used for subgeometries and as you
> > >>>> say
> > >>>> (I saw the blog too) the natural ordering of the edges should make the
> > >>>> tree
> > >>>> very effective.
> > >>>>>
> > >>>>
> > >>>>>
> > >>>> But I think you have to cache the tree to beat my calculation :-)
> > >>>>>
> > >>>> That belive comes from some trying I did when writing the code, before I
> > >>>> had
> > >>>> found the qsort function. Then I build a tree as described in that
> > >>>> C-bible I
> > >>>> can't remember the name, just to get the measure-values ordered. I think
> > >>>> it
> > >>>> was the number of memory-allocations that showed to be very expensive. I
> > >>>> might have done som elementary mistake but when I tried that tree with
> > >>>> one
> > >>>> node per vertex on the largest polygon of Alaska (about 70000 vertexes)
> > >>>> it
> > >>>> used almost 7 seconds just to build the tree and read it ordered. The
> > >>>> whole
> > >>>> calculation for distance between the largest polygons in Alaska and Texas
> > >>>> now uses less than 100 ms. But it is quite likely that I had done som
> > >>>> mistake in my treebuilding.
> > >>>>>
> > >>>> (That calculation Alaska Texas is extremly fast because Texas has that
> > >>>> sharp
> > >>>> edge aginst Alaska which is easy for my algoritm to catch.)
> > >>>>>
> > >>>>
> > >>>>>
> > >>>> /Nicklas
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>>
> > >>>>
> > >>>>>
> > >>>>> 2009-12-01 Nicklas Avén wrote:
> > >>>>>
> > >>>>> >
> > >>>>>
> > >>>> wow, I think postgis will be hard to beat in the long run :-)
> > >>>>> >
> > >>>>
> > >>>>> >
> > >>>> I'm not used to study those tree things, but it will be very interesting
> > >>>> to
> > >>>> follow this and try to understand it.
> > >>>>> >
> > >>>> Will it work on overlapping bboxes too?
> > >>>>> >
> > >>>>
> > >>>>> >
> > >>>> One thing I think is nice about "my" way of doing it, is that there is no
> > >>>> indexes included. The gain is that it can be nested in subqueries
> > >>>> and CTE's
> > >>>> without loosing the speed. But I haven't really understood when that
> > >>>> problem
> > >>>> occur of not using the indexes.
> > >>>>> >
> > >>>>
> > >>>>> >
> > >>>> I have been thinking some in 3D terms too, totally without knowledge
> > >>>> about
> > >>>> reality. But it shouldn't be too impossible to do the same tricks in 3D
> > >>>> and
> > >>>> calculating point to surface instead of point to segment. But that would
> > >>>> need a 3D type. I don't know how that use to be built, but I have
> > >>>> imagined a
> > >>>> list of 3D points and a related list with pointidentifiers in groups of
> > >>>> three, defining triangels. Then it would be quite fast to do like my
> > >>>> distance trick on the points and finding the surfaces to calculate
> > >>>> distances
> > >>>> to with some index on the pointidentifiers list...
> > >>>>> >
> > >>>>
> > >>>>> >
> > >>>> /Nicklas
> > >>>>> >
> > >>>>
> > >>>>> >
> > >>>>
> > >>>>> >
> > >>>>> >
> > >>>>> > 2009-12-01 Paul Ramsey wrote:
> > >>>>> >
> > >>>>> > Niklas,
> > >>>>> > >
> > >>>>> > >Your cunning sorting trick got into my head and I thought and thought
> > >>>>> > >on it and ended up borrowing the magic tree idea from Mark's prepared
> > >>>>> > >p-i-p code, and added another dimension to that, so the trees are
> > >>>>> > >actually in 2d space, and then starting thinking about how, given two
> > >>>>> > >of these trees you could quickly find things like intersections or
> > >>>>> > >even (*gasp*) distances...
> > >>>>> > >
> > >>>>> > >geog=# select distance(buffer('POINT(3 3)', 2),buffer('POINT(0 0)',
> > >>>>> > > 2));
> > >>>>> > > distance
> > >>>>> > >-------------------
> > >>>>> > > 0.242640687119285
> > >>>>> > >(1 row)
> > >>>>> > >
> > >>>>> > >geog=# select npoints(buffer('POINT(3 3)', 2));
> > >>>>> > > npoints
> > >>>>> > >---------
> > >>>>> > > 33
> > >>>>> > >(1 row)
> > >>>>> > >
> > >>>>> > >geog=# select 33*33;
> > >>>>> > > ?column?
> > >>>>> > >----------
> > >>>>> > > 1089
> > >>>>> > >(1 row)
> > >>>>> > >
> > >>>>> > >These two circles have 33 points each, so the brute force method
> > >>>>> > >requires 1089 distance calculations to come up with an answer. The
> > >>>>> > >magic trees took 29. It's also possible to *cache* the trees and
> > >>>>> > >re-use them, both for distance calculations and intersections and
> > >>>>> > >containments.
> > >>>>> > >
> > >>>>> > >Very exciting stuffs!
> > >>>>> > >
> > >>>>> > >However, we're almost to 1.5 and adding all the features you already
> > >>>>> > >have in your code (maximums, points and lines of shortness, etc)
> > >>>>> > > would
> > >>>>> > >take way too long. And I'm not sure my code is actually faster. Just
> > >>>>> > >that it's much faster than the brute force ways.
> > >>>>> > >
> > >>>>> > >It's all in lwtree.c in liblwgeom if you want to look.
> > >>>>> > >
> > >>>>> > >P.
> > >>>>> > >_______________________________________________
> > >>>>> > >postgis-devel mailing list
> > >>>>> > >postgis-devel@...
> > >>>>> > >postgis.refractions.net/mailman/listinfo/postgis-devel
> > >>>>> > >
> > >>>>> > >
> > >>>> _______________________________________________
> > >>>> postgis-devel mailing list
> > >>>> postgis-devel@...
> > >>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> > >>>>
> > >>>>
> > >>>_______________________________________________
> > >>>postgis-devel mailing list
> > >>>postgis-devel@...
> > >>>postgis.refractions.net/mailman/listinfo/postgis-devel
> > >>>
> > >>>
> > >> _______________________________________________
> > >> postgis-devel mailing list
> > >> postgis-devel@...
> > >> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> > >>
> > >>
> > >_______________________________________________
> > >postgis-devel mailing list
> > >postgis-devel@...
> > >postgis.refractions.net/mailman/listinfo/postgis-devel
> > >
> > >

_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

Re: [PostGIS] #342: [wktraster] Implement ST_AsPNG function for raster

2009-12-08T13:26:49Z

#342: [wktraster] Implement ST_AsPNG function for raster
------------------------+---------------------------------------------------
Reporter: mloskot | Owner: mloskot
Type: task | Status: assigned
Priority: medium | Milestone: WKTRaster 0.1.6
Component: wktraster | Version:
Resolution: | Keywords:
------------------------+---------------------------------------------------
Changes (by mloskot):

* owner: pracine => mloskot
* status: new => assigned

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/342#comment:1>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[PostGIS] #342: [wktraster] Implement ST_AsPNG function for raster

2009-12-08T13:26:42Z

#342: [wktraster] Implement ST_AsPNG function for raster
-----------------------+----------------------------------------------------
Reporter: mloskot | Owner: pracine
Type: task | Status: new
Priority: medium | Milestone: WKTRaster 0.1.6
Component: wktraster | Version:
Keywords: |
-----------------------+----------------------------------------------------
This tasks belongs to the Objective 0.1.6f specified in the
[wiki:WKTRaster WKT Raster]
[wiki:WKTRaster/PlanningAndFunding roadmap]

''to be discussed here''

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/342>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

Re: [PostGIS] #341: [wktraster] Implement ST_AsTIFF function for raster

2009-12-08T13:26:07Z

#341: [wktraster] Implement ST_AsTIFF function for raster
------------------------+---------------------------------------------------
Reporter: mloskot | Owner: mloskot
Type: task | Status: assigned
Priority: medium | Milestone: WKTRaster 0.1.6
Component: wktraster | Version:
Resolution: | Keywords:
------------------------+---------------------------------------------------
Changes (by mloskot):

* owner: pracine => mloskot
* status: new => assigned

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/341#comment:1>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[PostGIS] #341: [wktraster] Implement ST_AsTIFF function for raster

2009-12-08T13:25:54Z

#341: [wktraster] Implement ST_AsTIFF function for raster
-----------------------+----------------------------------------------------
Reporter: mloskot | Owner: pracine
Type: task | Status: new
Priority: medium | Milestone: WKTRaster 0.1.6
Component: wktraster | Version:
Keywords: |
-----------------------+----------------------------------------------------
This tasks belongs to the Objective 0.1.6f specified in the
[wiki:WKTRaster WKT Raster]
[wiki:WKTRaster/PlanningAndFunding roadmap]

''to be discussed here''

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/341>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

Re: [PostGIS] #340: [wktraster] Implement ST_AsJPEG function for raster

2009-12-08T13:24:56Z

#340: [wktraster] Implement ST_AsJPEG function for raster
------------------------+---------------------------------------------------
Reporter: mloskot | Owner: mloskot
Type: task | Status: assigned
Priority: medium | Milestone: WKTRaster 0.1.6
Component: wktraster | Version:
Resolution: | Keywords:
------------------------+---------------------------------------------------
Changes (by mloskot):

* owner: pracine => mloskot
* status: new => assigned

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/340#comment:1>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[PostGIS] #340: [wktraster] Implement ST_AsJPEG function for raster

2009-12-08T13:24:49Z

#340: [wktraster] Implement ST_AsJPEG function for raster
-----------------------+----------------------------------------------------
Reporter: mloskot | Owner: pracine
Type: task | Status: new
Priority: medium | Milestone: WKTRaster 0.1.6
Component: wktraster | Version:
Keywords: |
-----------------------+----------------------------------------------------
This tasks belongs to the Objective 0.1.6f specified in the
[wiki:WKTRaster WKT Raster]
[wiki:WKTRaster/PlanningAndFunding roadmap]

''to be discussed here''

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/340>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

Re: [PostGIS] #339: [wktraster] Implement ST_Band function for raster

2009-12-08T13:23:15Z

#339: [wktraster] Implement ST_Band function for raster
------------------------+---------------------------------------------------
Reporter: mloskot | Owner: mloskot
Type: task | Status: assigned
Priority: medium | Milestone: WKTRaster 0.1.6
Component: wktraster | Version:
Resolution: | Keywords:
------------------------+---------------------------------------------------
Changes (by mloskot):

* owner: pracine => mloskot
* status: new => assigned

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/339#comment:1>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[PostGIS] #339: [wktraster] Implement ST_Band function for raster

2009-12-08T13:23:09Z

#339: [wktraster] Implement ST_Band function for raster
-----------------------+----------------------------------------------------
Reporter: mloskot | Owner: pracine
Type: task | Status: new
Priority: medium | Milestone: WKTRaster 0.1.6
Component: wktraster | Version:
Keywords: |
-----------------------+----------------------------------------------------
This tasks belongs to the Objective 0.1.6f specified in the
[wiki:WKTRaster WKT Raster]
[wiki:WKTRaster/PlanningAndFunding roadmap]

''to be discussed here''

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/339>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

Re: [PostGIS] #165: [wktraster] missing uninstall target

2009-12-08T12:50:43Z

#165: [wktraster] missing uninstall target
------------------------+---------------------------------------------------
Reporter: kneufeld | Owner: pracine
Type: defect | Status: new
Priority: medium | Milestone: WKTRaster 0.1.6
Component: wktraster | Version:
Resolution: | Keywords:
------------------------+---------------------------------------------------
Changes (by mloskot):

* summary: [wktraster]: missing uninstall => [wktraster] missing
uninstall target

Old description:

> There is no installation cleanup mechanism in place yet.
>
> [buildbot@falcon wktraster]$ make uninstall
>
> make: *** No rule to make target `uninstall'. Stop.

New description:

There is no installation cleanup mechanism in place yet.

{{{
[buildbot@falcon wktraster]$ make uninstall

make: *** No rule to make target `uninstall'. Stop.
}}}

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/165#comment:4>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

Re: [PostGIS] #164: [wktraster] configure script option --prefix not recognized

2009-12-08T12:50:28Z

#164: [wktraster] configure script option --prefix not recognized
------------------------+---------------------------------------------------
Reporter: kneufeld | Owner: pracine
Type: defect | Status: new
Priority: medium | Milestone: WKTRaster 0.1.6
Component: wktraster | Version:
Resolution: | Keywords:
------------------------+---------------------------------------------------
Changes (by mloskot):

* summary: [wktraster]: --prefix not recognized => [wktraster] configure
script option --prefix not recognized

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/164#comment:6>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

Re: [PostGIS] #152: [wktraster] raster_columns out-db field should be an array

2009-12-08T12:50:05Z

#152: [wktraster] raster_columns out-db field should be an array
------------------------+---------------------------------------------------
Reporter: pracine | Owner:
Type: defect | Status: new
Priority: high | Milestone: WKTRaster 0.1.6
Component: wktraster | Version:
Resolution: | Keywords:
------------------------+---------------------------------------------------
Changes (by mloskot):

* summary: [wktraster]: raster_columns out-db field should be an array
=> [wktraster] raster_columns out-db field
should be an array

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/152#comment:6>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

Re: [PostGIS] #169: [wktraster] make check target spits out a lot of WARNINGS and several ERRORs

2009-12-08T12:49:57Z

#169: [wktraster] make check target spits out a lot of WARNINGS and several
ERRORs
--------------------------+-------------------------------------------------
Reporter: pracine | Owner: mloskot
Type: enhancement | Status: assigned
Priority: medium | Milestone:
Component: wktraster | Version:
Resolution: | Keywords:
--------------------------+-------------------------------------------------
Changes (by mloskot):

* summary: [wktraster]: "make check" target spits out a lot of WARNINGS
and several ERRORs => [wktraster] make check
target spits out a lot of WARNINGS and several
ERRORs

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/169#comment:4>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel