Opened 6 years ago

Closed 6 years ago

#4304 closed patch (fixed)

Add seed parameter to ST_GeneratePoints

Reported by: mwtoews Owned by: komzpa
Priority: blocker Milestone: PostGIS 3.0.0
Component: postgis Version: master
Keywords: Cc:

Description

An idea from #2131 is to modify ST_GeneratePoints to add a seed parameter to optionally allow reproducible pseudo-random points, i.e.:

ST_GeneratePoints(g geometry, npoints numeric, seed numeric DEFAULT NULL)

One challenging component to this feature request is to ensure that the pseudo-random sequence is portable across different OSes/hardware.

Change History (12)

comment:1 by mwtoews, 6 years ago

Note that I've already started this feature request, and will switch the ticket type to "patch" when ready for review.

So far, testing a few simple GPL-licensed functions by John Burkardt. Results from r8_random and r8_uni appear to provide similar numbers to the output values from 2008 on 64-bit Windows, x86 Linux, and a MIPS virtual machine. Another good resource is R.

comment:2 by mwtoews, 6 years ago

Type: enhancementpatch

See https://github.com/postgis/postgis/pull/365 which implements this stuff (hopefully!)

comment:3 by pramsey, 6 years ago

Owner: changed from pramsey to mwtoews

comment:4 by komzpa, 6 years ago

Resolution: fixed
Status: newclosed

In 17248:

Add seed parameter for ST_GeneratePoints.

Patch by Mike Taves.

Closes #4299
Closes #4304
Closes https://github.com/postgis/postgis/pull/365

comment:5 by Algunenano, 6 years ago

Priority: mediumblocker
Resolution: fixed
Status: closedreopened

Dronie isn't happy about this patch, it appears to fail when checking upgrades (but it's not clear in the final message).

The npoints parameter has changed from numeric to integer. Should the old signature moved to legacy so the upgrade is possible?

comment:6 by Algunenano, 6 years ago

Owner: changed from mwtoews to komzpa
Status: reopenednew

comment:7 by komzpa, 6 years ago

In 17251:

Fix upgrades.

References #4304

comment:8 by komzpa, 6 years ago

Drone is okay on 9.6 but says out of memory on 10 build. Is it a thing to be fixed on the drone's machine itself?

cat postgis_drop_before.sql postgis_upgrade_for_extension.sql.in postgis_drop_after.sql | /usr/bin/perl -pe 's/BEGIN\;//g ; s/COMMIT\;//g' > postgis_upgrade_for_extension.sql
echo "BEGIN;" > postgis_upgrade.sql
cat postgis_drop_before.sql postgis_upgrade.sql.in postgis_drop_after.sql >> postgis_upgrade.sql
echo "COMMIT;" >> postgis_upgrade.sql
virtual memory exhausted: Cannot allocate memory
virtual memory exhausted: Cannot allocate memory
make[1]: *** [lwgeom_spheroid.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [lwgeom_functions_basic.o] Error 1
make[1]: Leaving directory `/drone/src/postgis'
make: *** [all] Error 1

comment:9 by strk, 6 years ago

I would drop the -j switch in the make call found in .drone-1.0.yml

It was added in r17012 [5ddfbd617c47dd0e963cda81e44feadb2f16115a/git] with an unrelated commit log …

comment:10 by komzpa, 6 years ago

Dropping -j will slow down the build, which isn't great for CI. Travis allocates 8 GB RAM for each build and never bumps into similar problems. What is the size of such limit in Drone and what can we do to raise it?

comment:11 by strk, 6 years ago

Drone limits are on a per-agent basis. The current set of drone agents, for Drone-1.0, should be found on the OSGeo wiki. Regina knows more about it. There could be a misconfiguration there

comment:12 by komzpa, 6 years ago

Resolution: fixed
Status: newclosed

All issues with bots are now only about #4329.

Note: See TracTickets for help on using tickets.