Opened 14 years ago

Closed 14 years ago

#384 closed defect (fixed)

documentation and clearifying of ~= change

Reported by: nicklas Owned by: nicklas
Priority: medium Milestone: PostGIS 1.5.0
Component: postgis Version: master
Keywords: Cc:

Description

The change #282 in behavior of ~= operator from working as a fast variant of st_OrderingEqual to just comparing bboxes is not documentated.

This was a result from discussions in #253

I don't know those different index approaches enough to understand this.

What is now the diffeence between operator = and ~=

Why use && in ST_Equals and new ~= in ST_OrderingEquals

Maybe should have been more tickets, but I don't know what here is valid questions.

/Nicklas

Attachments (1)

operator_doc.patch (2.9 KB ) - added by nicklas 14 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 by pramsey, 14 years ago

Milestone: PostGIS 1.5.0PostGIS 1.5.1

I'm deferring this, since I hate all operators except && and can't believe anyone uses them. I think we have problems fundamentally with the '=' operator, since people have such strong internalized notions of what it means. BTW, the difference between = and ~= is what opclass they are defined for. = is defined on the btree and ~= on the gist index.

comment:2 by pramsey, 14 years ago

Owner: changed from pramsey to robe

comment:3 by robe, 14 years ago

The difference is that = doesn't use an index and ~= uses an index. Except for the rare case if you put a btree index on a geometry which you can only do for small thngs like points.

Am I safe in saying that we can never make = use a gist index as I assume since a gist is marked as lossy, it would never be able to be used in group by, order by etc. Perhaps Paul, Mark or Kevin can confirm my understanding of this.

Ideally we would just use = and scrap ~=, but we can't because we need a fast bounding box check. Huh Paul yap I am and I think Kevin too are those unbelievable people you talk about. ~= is important (well an indexable bounding box equality operator)

comment:4 by nicklas, 14 years ago

I will try to come up with some rough doc before final release of 1.5.0
Now the doc gives wrong information, and I guess some poor information is better than wrong information.

The problem I think is that ~= was that much faster solution than ST_OrderingEquals in 1.4 and below. Because of that it might be quite commonly used.

And the difference between bounding box comparation and geometry_same will not show in majority of situations but might be a very important difference in others.

comment:5 by robe, 14 years ago

Milestone: PostGIS 1.5.1PostGIS 1.5.0
Owner: changed from robe to nicklas

Nicklas,

I'll take that as a volunteer from you it shove it over to you. Hmm this is beginning to feel like musical chairs.

Probably worthwhile noting that since the operator can't be dropped, if you soft upgraded from PostGIS 1.3 and never did a hard upgrade ~= still behaves like an exact geometry operator and if you soft-upgraded. If your first version of PostGIS was 1.4.0 then it behaves like a bbox operator, but if you soft-upgraded from 1.4.1 (that being your first version or did a hard upgrade, then it behaves like a geometry equality operator).

comment:6 by nicklas, 14 years ago

ok, this seems to be more messy than I suspected.

I will give it a try but I can't until tomorrow evening so don't wait for it with RC1.

I guess the most important information to give in doc is "Stay away, don't use it, because the behavior is more unpredictable than coming weather" but maybe in other words :-)

comment:7 by robe, 14 years ago

Yap that sounds like a good description — use ST_OrderingEquals instead

comment:8 by nicklas, 14 years ago

Here comes a suggested text for doc of ~= operator, attached as patch.

I haven't successed to get the dependencies in place to make the documentation, so I didn't want to commit it when I haven't seen the result.

/Nicklas

by nicklas, 14 years ago

Attachment: operator_doc.patch added

comment:9 by robe, 14 years ago

Nicklas,

Just commit it. I'm not setup to build the documentation either. I just wait for hudson to complain if there are issues and also use my trusty xml error checker in my JEdit IDE. It won't break anything on the site if you have mistakes, just won't build a new PDF file or html document if it has errors which is not a big deal.

comment:10 by nicklas, 14 years ago

Ok, I have committed at r5161.

But I missed to comment the commit :-( What to do then?

/Nicklas

comment:11 by robe, 14 years ago

Resolution: fixed
Status: newclosed
Version: trunk

I don't think our SVN settings allow back commenting, since I tried and got a repository's pre-revprop-change hook failed or is non-existent. I think I've gotten that same error before when trying to change my own comments.

Anyrate we'll survive somehow with this missing comment. :)

The doc looks fine to me so closing this out.

Note: See TracTickets for help on using tickets.