[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgis-devel
Subject:    Re: [postgis-devel] Proposal: Adding buffer parameter to ST_TileEnvelope()
From:       Yuri Astrakhan <yuriastrakhan () gmail ! com>
Date:       2019-12-07 17:42:25
Message-ID: CAJGfNe9mnCf=e_UrA3JW5_KqsSGdAq3+4hFWzHHKE4gDuP49Cw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


What should the next steps be to get
https://github.com/postgis/postgis/pull/514 merged?  Are there any blockers
or required TODOs?  Thanks!

On Thu, Nov 14, 2019 at 2:29 PM Yuri Astrakhan <yuriastrakhan@gmail.com>
wrote:

> How should we grow tiles then with regards to the bounds parameter?  I see
> two approaches:
> * bbox longitude (x) is not clipped unless it grows wider than the bounds,
> in which case the result spans the whole bounding box. Latitude (y) is
> always clipped.
>     PROs: makes it possible to use with geometry columns without any extra
> modifications.
>     CONs: might cause confusion because the result could be outside of
> bounds, and because it might not match geometries across antimeredian.
> * bbox grows up to the bounds, and then gets clipped.
>     PROs: all generated bboxes are within the bounds, using it as filter
> always matches real data in the geometry columns.
>     CONs: have to manually extend it across antimeredian if needed.
>
> I'm inclined to go with the first approach, would that be ok?
>
> On Thu, Nov 14, 2019 at 7:58 AM Paul Ramsey <pramsey@cleverelephant.ca>
> wrote:
>
>>
>>
>> On Nov 13, 2019, at 11:35 PM, Yuri Astrakhan <yuriastrakhan@gmail.com>
>> wrote:
>>
>> Rough implementation PR - https://github.com/postgis/postgis/pull/514
>>
>> I am having some issues with unit tests (too much magic in auto-generated
>> code?), so a Postgis guru's help might be needed.
>>
>> One open concern: extending envelope beyond antimeredian. Is this
>> possible? Would a bbox from the tile that overflows to the other side of
>> antimeredian match any geometries? For example, given two points - one at
>> -179, and the other is at +179 (longitude), would they be found with the
>> bbox that goes from -200..-160 ?
>>
>>
>> In geometry they would not match, in geography they would.
>>
>> P
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
>

[Attachment #5 (text/html)]

<div dir="ltr">What should the next steps be to get  <a \
href="https://github.com/postgis/postgis/pull/514">https://github.com/postgis/postgis/pull/514</a> \
merged?   Are there any blockers or required TODOs?   Thanks!</div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 14, 2019 at 2:29 PM \
Yuri Astrakhan &lt;<a \
href="mailto:yuriastrakhan@gmail.com">yuriastrakhan@gmail.com</a>&gt; \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">How \
should we grow tiles then with regards to the bounds parameter?   I see two \
approaches:<div>* bbox longitude (x) is not clipped unless it grows wider than the \
bounds, in which case the result spans the whole bounding box. Latitude (y) is always \
clipped.</div><div>      PROs: makes it possible to use with geometry columns without \
any extra modifications.</div><div>      CONs: might cause confusion because the \
result could be outside of bounds, and because it might not match geometries across  \
antimeredian.<br><div>* bbox grows up to the bounds, and then gets \
clipped.</div><div>      PROs: all generated bboxes are within the bounds, using it \
as filter always matches real data in the geometry columns.</div><div>      CONs: \
have to manually extend it across  antimeredian if \
needed.</div></div><div><br></div><div>I&#39;m inclined to go with the first \
approach, would that be ok?</div></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Thu, Nov 14, 2019 at 7:58 AM Paul Ramsey &lt;<a \
href="mailto:pramsey@cleverelephant.ca" \
target="_blank">pramsey@cleverelephant.ca</a>&gt; wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div><br><div><br><blockquote type="cite"><div>On \
Nov 13, 2019, at 11:35 PM, Yuri Astrakhan &lt;<a \
href="mailto:yuriastrakhan@gmail.com" target="_blank">yuriastrakhan@gmail.com</a>&gt; \
wrote:</div><br><div><div dir="ltr"><div dir="ltr">Rough implementation PR -  <a \
href="https://github.com/postgis/postgis/pull/514" \
target="_blank">https://github.com/postgis/postgis/pull/514</a><br></div><div \
dir="ltr"><div><br></div><div>I am having some issues with unit tests (too much magic \
in auto-generated code?), so a Postgis guru&#39;s help might be \
needed.</div></div><div><br></div><div>One open concern: extending envelope beyond \
antimeredian. Is this possible? Would a bbox from the tile that overflows to the \
other side of antimeredian match any geometries? For example, given two points - one \
at -179, and the other is at  +179 (longitude), would they be found with the bbox \
that goes from -200..-160 ?</div></div></div></blockquote><div><br></div><div>In \
geometry they would not match, in geography they \
would.</div><div><br></div><div>P</div><br><blockquote type="cite"><div><div \
dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
class="gmail_quote"></div> </blockquote></div></div>
_______________________________________________<br>postgis-devel mailing list<br><a \
href="mailto:postgis-devel@lists.osgeo.org" \
target="_blank">postgis-devel@lists.osgeo.org</a><br><a \
href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" \
target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></div></blockquote></div><br></div>_______________________________________________<br>
 postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" \
target="_blank">postgis-devel@lists.osgeo.org</a><br> <a \
href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" \
target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div>
 </blockquote></div>


[Attachment #6 (text/plain)]

_______________________________________________
postgis-devel mailing list
postgis-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/postgis-devel

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic