cartodb/crankshaft
1
0
Fork 0
mirror of https://github.com/CartoDB/crankshaft.git synced 2024-11-01 10:20:48 +08:00
Code Issues Packages Projects Releases Wiki Activity
760 Commits 94 Branches 23 Tags 3.1 MiB
Python 65.5%
PLpgSQL 32.7%
Jupyter Notebook 1.6%
4a81710749
Go to file
Rafa de la Torre 4a81710749 Upgrade pysal to version 1.14.3 
This solves a problem with the Markov analysis. Otherwise, with some
inputs it gives the following error:

```
Analysis A2 failed:
ValueError: operands could not be broadcast together with shapes (5) (3)
```

The stack trace is the following:
```
ERROR:  ValueError: operands could not be broadcast together with shapes (5) (2)
CONTEXT:  Traceback (most recent call last):
  PL/Python function "cdb_spatialmarkovtrend", line 7, in <module>
    return markov.spatial_trend(subquery, time_cols, num_classes, w_type, num_ngbrs, permutations, geom_col, id_col)
  PL/Python function "cdb_spatialmarkovtrend", line 76, in spatial_trend
  PL/Python function "cdb_spatialmarkovtrend", line 416, in __init__
  PL/Python function "cdb_spatialmarkovtrend", line 498, in _mn_test
  PL/Python function "cdb_spatialmarkovtrend", line 526, in _ssmnp_test
PL/Python function "cdb_spatialmarkovtrend"
```

and here is the line where it actually fails:
https://github.com/pysal/pysal/blob/v1.11.2/pysal/spatial_dynamics/markov.py#L526

In v1.14.3, the `shtest` is opt-in. So this gives us a chance to curate data if we wanted to apply that test, optionally, instead of crashing:

https://github.com/pysal/pysal/blob/v1.14.3/pysal/spatial_dynamics/markov.py#L490
2018-02-22 16:15:52 +01:00
.github adds pep8 check item 2016-10-06 08:56:14 -04:00
doc Merge branch 'develop' into add-nonspatial-kmeans-w-class-framework 2018-01-09 13:47:29 -05:00
release Release 0.6.1 2017-11-23 10:07:52 +01:00
src Upgrade pysal to version 1.14.3 2018-02-22 16:15:52 +01:00
.brackets.json recommit from postgresql repo 2016-08-09 12:09:19 -04:00
.gitignore Ignore idea based configurations 2016-06-09 11:27:15 +02:00
.travis.yml Travis: Use postgresql 9.5.2-3 2017-10-31 11:38:20 +01:00
check-compatibility.sh Check function signatures 2016-08-10 19:39:39 +02:00
check-up-to-date-with-master.sh Do not check code is updated when not needed 2016-08-11 19:20:04 +02:00
CONTRIBUTING.md Update CONTRIBUTING with information about PG function labels 2017-11-23 10:07:52 +01:00
LICENSE Add licencse 2016-02-15 18:36:38 +01:00
Makefile Remove reference to clean-environments #60 2016-06-14 18:27:35 +02:00
Makefile.global Makefile: Add support for PARALLEL categories 2017-11-23 10:07:52 +01:00
NEWS.md Release 0.6.1 2017-11-23 10:07:52 +01:00
README.md Rebranding 2016-08-18 10:35:54 +02:00
RELEASE.md Update RELEASE process 2017-11-23 10:07:52 +01:00

README.md

Crankshaft Build Status

CARTO Spatial Analysis extension for PostgreSQL.

Code organization

  • doc/ documentation
  • src/ source code
  • pg/ contains the PostgreSQL extension source code
  • py/ Python module source code
  • release reseleased versions

Requirements

  • PostgreSQL
  • plpythonu and postgis extensions
  • python-scipy system package (see src/py/README.md)

Development Process

We distinguish two roles:

  • developers will implement new functionality and bugfixes into the codebase.
  • A release manager will handle the release process.

We use the branch develop as the main integration branch for development. The master is reserved to handle releases.

The process is as follows:

  1. Create a new topic branch from develop for any new feature or bugfix and commit their changes to it:
git fetch && git checkout -b my-cool-feature origin/develop
  1. Code, commit, push, repeat.
  2. Write some tests for your feature or bugfix.
  3. Update the NEWS.md doc.
  4. Create a pull request and mention relevant people for a peer review.
  5. Address the comments and improvements you get from the peer review.
  6. Mention @CartoDB/dataservices in the PR to get it merged into develop.

In order for a pull request to be accepted, the following criteria should be met:

  • The peer review should pass and no major issue should be left unaddressed.
  • CI tests must pass (travis will take care of that).

Development Guidelines

For a detailed description of the development process please see the CONTRIBUTING.md guide.

Testing

The tests (both for SQL and Python) are executed by running, from the top directory:

sudo make install
make test

Release

The release process is described in the RELEASE.md guide and is the responsibility of the designated release manager.