Java bindings and other java-related projects for PostGIS
postgis / postgis-java Goto Github PK
View Code? Open in Web Editor NEWjava bindings for postgis
java bindings for postgis
JDBC driver can not support new Geography type, and can not cast to a correctly java object.
eg. POINTZ
The postgresql.org jdbc driver is not the only jdbc driver available for postgresql. It would be nice to have the PostGIS jdbc extensions and related components work with other jdbc for postgresql as well. Maybe the hard dependencies can be factored out into a separate module so that bindings to other available jdbc drivers is possible.
Original idea was proposed on the postgis-devel mailing list by @frode-carlsen:
https://lists.osgeo.org/pipermail/postgis-devel/2015-June/025003.html
This new codebase needs reworked to adopt and establish new structure and build process/release process.
Can you provide a sample project or a quick start?
I think he can meet my needs.
But I don't know how to use it
xD
The current postgis-jdbc artifact has hard "compile" scope dependencies on logback. This wreaks havoc with all consumers that don't use logback since it will be added into the dependency tree transitively and collide with other slf4j logging providers (like log4j). Clients have to explicitly exclude the logback dependencies to prevent this.
The concrete logging provider should probably be in "provided" scope so it does not get transitively inherited by consumers.
BTW the logback dependency comes in via the parent "postgis-java-aggregator" project.
In order to release maven artifacts to Maven Central, the artifacts can be staged with sonatype OSSHR project which will handle verification of the artifact contents and then mirror them to the central repo.
There is a list of requirements for staged components which includes attaching source archives and javadoc archives to the artifacts. The javadocs are usually created automatically during the build process where there is linting of the javadoc content involved. Currently the codebase needs reworked to pass the more strict linting of Java8.
The latest version of postgis bindings (2021.1.0) contains very vulnarable dependency.
Can it be updated to major version?
https://mvnrepository.com/artifact/net.postgis/postgis-jdbc/2021.1.0
Thank in advance!
When run against the database, the ParserTest test class fails.
When the class fails, it's sending this data in the test dataset:
GEOMETRYCOLLECTIONM(POINT(10 10 20),POINT(20 20 20))
stacktrace:
org.postgresql.util.PSQLException: ERROR: can not mix dimensionality in a geometry Hint: "...ONM(POINT(10 10 20),POINT(20 20 20))" <-- parse error at position 53 within geometry at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2103) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1836) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:512) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:374) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:254) at org.postgis.ParserTest.viaSQL(ParserTest.java:373) at org.postgis.ParserTest.test(ParserTest.java:290) at org.postgis.ParserTest.testParser(ParserTest.java:242)
The equivalent function fails when run from psql:
postgis1=> select geometry_in('GEOMETRYCOLLECTIONM(POINT(10 10 20),POINT(20 20 20))'); ERROR: can not mix dimensionality in a geometry HINT: "...ONM(POINT(10 10 20),POINT(20 20 20))" <-- parse error at position 53 within geometry
The ParserTest
fails between PostGIS v2.4.4 and PostGIS v2.50 with the following error:
ParserTest.testParser:244->test:339 expected [POINT(1.0E100 0 -2.0E-5)] but found [POINT(1.0E100 1.2345E-100 -2.0E-5)]
Tests performed via psql with mdillon/postgis docker image between tags 9.3
and 9.4
show the breakage. The same test with tag 11-alpine
also shows the breakage.
In psql, the sql statement SELECT ST_AsEWKT(geometry_in('POINT(1e100 1.2345e-100 -2e-5)'));
returns different results between 9.3 and 9.4:
9.3 -> POINT(1e+100 1.2345e-100 -2e-05)
9.4 and 11-alpine -> and POINT(1e+100 0 -0.00002)
The 2021.1.0 version of postgis-java-jtsparser is not released to the maven central repository
Hi
question will this postgis jdbc 2.3 work with postgres 11 and postgis 2.5 ?
not sure how i need to look at the version number of this postgis jdbc is it related tot the postgis version or not at all ?
... if the JDBC driver is not applicable to the connection string.
Offending code: https://github.com/postgis/postgis-java/blob/main/postgis-jdbc/src/main/java/net/postgis/jdbc/DriverWrapper.java#L265
Background:
If one has multiple JDBC driver registered, DriverManager.getConnection
is called on each one of them until one driver declares it can handle the URL.
If that method throws an exception, then the "reason" is overwritten if multiple drivers are registered (e. g. Oracle, PostGis).
This causes an access attempt to an OracleDB with wrong password to return an Postgres error message.
This is because Oracle is tried and throws (correct, wrong password) and then Postgis can't handle it and also throws (not correct, should return null
), thereby overwriting the exception and hiding the underlying problem:
java.sql.SQLException: Unknown protocol or subprotocol in url jdbc:oracle:thin:@oracle16.example.com:1521:oracle16
at net.postgis.jdbc.DriverWrapper.mangleURL(DriverWrapper.java:265)
at net.postgis.jdbc.DriverWrapper.connect(DriverWrapper.java:159)
at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:681)
at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:190)
If you agree with the assessment, would you accept a PR?
PostGIS supports several types of arc and curve geometries, which the JDBC driver apparently does not support. A simple fallback might be to invoke ST_CurveToLine if any circular string (Arc) or Curve is encountered.
VersionPrinter test class throws an error:
Caught SQLException while attempting query: org.postgresql.util.PSQLException ERROR: function postgis_uses_stats() does not exist
This is a non-fatal exception as far as the test suite is concerned. It does not fail the build. Perhaps all of the version checks in this test will need to be revisited.
https://github.com/postgis/postgis-java/blob/master/jdbc/src/test/java/org/postgis/VersionPrinter.java#L49
In a PostGis database is a CircularString (EWKT) Geometry. It was inserted via this SQL:
INSERT INTO objectwithgeometries (id,geometry,remarks) VALUES ( 41, ST_SetSRID( ST_GeomFromEWKT( 'CIRCULARSTRING(29.8925 41.36667,29.628611 41.015000,29.27528 41.31667)'), 4326), 'remark-3');
Try 1: When reading with Spring JPA repo.findAll() (with a connection to Postgis including Postgis dialect) I get this error:
org.geolatte.geom.codec.WkbDecodeException: Unsupported WKB type code: 8
Try 2: Then I tried with:
List<Map<String, Object>> objects = jdbcTemplate.queryForList( String.format( "select id,geometry,remarks from objectwithgeometries where id = %d", id));
objects.forEach( r -> {
WKBReader wkbReader = new WKBReader();
PGobject geometryObject = (PGobject) r.get( "geometry");
byte[] geom = WKBReader.hexToBytes( geometryObject.getValue() );
try {
log.info( "Geometry: {}", wkbReader.read(geom));
} catch (ParseException e) {
throw new RuntimeException(e);
}
});
I got this error:
This will also throw the exception: org.locationtech.jts.io.ParseException: Unknown WKB type 8
Try 3: using PGobject, PGGeometry, etc. These objects are available via the maven dependency:
<dependency>
<groupId>net.postgis</groupId>
<artifactId>postgis-jdbc</artifactId>
<version>2023.1.0</version>
</dependency>
The problem with this is that it gives an error (Unknown Geometry Type: 8) during the jdbcTemplate.queryForList() ;-(.
Try-4: standalone example via a different approach. The effect is the same: Unknown Geometry Type: 8.
Class.forName("org.postgresql.Driver");
String url = "jdbc:postgresql://localhost:5433/postgis";
conn = DriverManager.getConnection(url, "xyz", "abc");
((org.postgresql.PGConnection)conn).addDataType("geometry",
(Class<? extends PGobject>) Class.forName("net.postgis.jdbc.PGgeometry"));
Statement s = conn.createStatement();
ResultSet r = s.executeQuery("select id,geometry,remarks from objectwithgeometries where id = 43");
while( r.next() ) {
PGgeometry geom = (PGgeometry)r.getObject(2);
int id = r.getInt(1);
System.out.println("Row " + id + ":");
System.out.println(geom.toString());
}
s.close();
conn.close();
How to read this (EWKT) object?
目前没看到继续提交新的代码,不了解此项目是否会继续开展。
Hi
We encountered an issue with a DB having several Postgis schemas. When the app starts and we issue a find on a table having a Geometry, the type
is not geometry
but \"public\".\"geometry\"
.
Strangely, if we issue a save to the table, and next a find, the type
is correct.
To workaround this, we modified the JDBC driver to add the mapping between \"public\".\"geometry\"
and PGgeometry
.
The PR is coming...
Best regards.
Geoff.
JtsParserTest test class throws an error:
org.postgresql.util.PSQLException: ERROR: function asewkt(geometry) does not exist
This error only occurs when the testWithDatabase flag is true in the build. When the flag is set to false, no testing against a database occurs. Currently the flag is set to false by default, so the error does not occur and the running the testsuite is fine.
OSGEO Live uses OpenJDK 7 so going beyond 1.7 is undesirable at this point in time.
ParserTest test class throws an error:
org.postgresql.util.PSQLException: ERROR: function asewkt(geometry) does not exist
This error only occurs when the testWithDatabase flag is true in the build. When the flag is set to false, no testing against a database occurs. Currently the flag is set to false by default, so the error does not occur and the running the testsuite is fine.
Hi,
I am having an issue with your library when I attempt to use it in conjunction with a Postgres data source.
The following very basic code:
final String url = DriverWrapper.POSTGIS_PROTOCOL + "//127.0.0.1:5432/postgres";
BaseDataSource ds = new PGSimpleDataSource();
ds.setUrl(url);
ds.setUser("postgres");
ds.setPassword("postgres");
Connection conn = ds.getConnection();
System.out.println(conn.toString());
Produces the error:
Exception in thread "main" java.lang.IllegalArgumentException: URL invalid jdbc:postgresql_postGIS://127.0.0.1:5443/postgres
at org.postgresql.ds.common.BaseDataSource.setUrl(BaseDataSource.java:1367)
at com.runwaysdk.Sandbox.main(Sandbox.java:76)
Due primarily to the fact that the Postgres BaseDataSource includes hardcoded assumptions that the jdbc protocol will always be 'postgresql'. See here and here.
Am I doing something wrong here? All of your test code appears to use the DriverManager.getConnection
interface, which works because it bypasses that DataSource abstraction.
Additionally, I am unable to bypass your DriverWrapper, due to the fact that it is auto-loaded by the Java service loader paradigm. This causes issues because if I do not use the 'postgresql_postGIS' protocol, when DriverManager.getConnection is invoked via BaseDataSource.getConnection
, the DriverWrapper throws a SQL exception Unknown protocol or subprotocol in url
. This is already documented as an issue in ticket #113. As a result, I fear that my only path forward might be to repackage your jar without the META-INF service loader file, or to repackage the jar with a fix for #113 included.
Thanks
Modify CI to push snapshot builds to sonatype/maven central
PGgeometry
in it's current form (version 2.2.1) uses an instance of BinaryParser
as a field. BinaryParser
itself is not serializable, thereby breaking the contract of the base class PGobject implements Serializable
.
While using postgis-2.1.8.tar.gz PostGIS JDBC extension with PG9.5 following anomalies are observed i.e.
Version.getFullVersion() method returning wrong version i.e.
PostGIS JDBC V2.0.0
It seems that related version information require to be updated i.e.
java/jdbc/src/org/postgis/version.properties
REL_MAJOR_VERSION=2
REL_MINOR_VERSION=0
REL_MICRO_VERSION=0
Test case java/jdbc/src/examples/TestParser.java fail with two type of errors i.e.
A). There are # of failure because of "can not mix dimensionality in a geometry", It seems a test case bug.
2016-02-05 11:19:54 PKT ERROR: can not mix dimensionality in a geometry 2016-02-05 11:19:54 PKT HINT: "...IONM(POINT(10 10 20),POINT(20 20 20))" <-- parse error at position 52 within geometry 2016-02-05 11:19:54 PKT STATEMENT: SELECT geometry_in('GEOMETRYCOLLECTIONM(POINT(10 10 20),POINT(20 20 20))')
Test case output snippet i.e.
Testing on connection 0: postgres
--- Server side error: org.postgresql.util.PSQLException: ERROR: can not mix dimensionality in a geometry
Hint: "...ONM(POINT(10 10 20),POINT(20 20 20))" <-- parse error at position 53 within geometry
SQLout : GEOMETRYCOLLECTIONM(POINTM(10 10 20),POINTM(20 20 20))
Eq SQLout: yes
Prepared: GEOMETRYCOLLECTIONM(POINTM(10 10 20),POINTM(20 20 20))
Eq Prep: yes
--- Server side error: org.postgresql.util.PSQLException: ERROR: can not mix dimensionality in a geometry
Hint: "...ONM(POINT(10 10 20),POINT(20 20 20))" <-- parse error at position 53 within geometry
--- Server side error: org.postgresql.util.PSQLException: ERROR: can not mix dimensionality in a geometry
Hint: "...ONM(POINT(10 10 20),POINT(20 20 20))" <-- parse error at position 53 within geometry
hexNWKT: GEOMETRYCOLLECTIONM(POINTM(10 10 20),POINTM(20 20 20))
equal : yes
hexXWKT: GEOMETRYCOLLECTIONM(POINTM(10 10 20),POINTM(20 20 20))
equal : yes
NWKT: GEOMETRYCOLLECTIONM(POINTM(10 10 20),POINTM(20 20 20))
equal : yes
XWKT: GEOMETRYCOLLECTIONM(POINTM(10 10 20),POINTM(20 20 20))
equal : yes
You can observe that test case is using POINT instead of POINTM for some cases that is troubling PostGIS.
B). Second set of errors are failing with following errors i.e.
2016-02-05 11:19:55 PKT ERROR: parse error - invalid geometry
2016-02-05 11:19:55 PKT HINT: "GEOMETRYCOLLECTION(EMPTY" <-- parse error at position 24 within geometry
2016-02-05 11:19:55 PKT STATEMENT: SELECT geometry_in('GEOMETRYCOLLECTION(EMPTY)')
It looks like a bug to me that result in query like "SELECT geometry_in('GEOMETRYCOLLECTION(EMPTY)')" instead of "SELECT geometry_in('GEOMETRYCOLLECTION EMPTY')" i.e. new representation.
I have also reported this issue on https://trac.osgeo.org/postgis/ticket/3453.
I upgraded JTS to 1.16.0 and things seem to be working ok.
There were some superficial changes to the constructors of PackedCoordinateSequence.Double()
Hi,
Any chance this can be deployed to maven central repository?
Thanks
The file META-INF/services/java.sql.Driver
should contain the string org.postgis.DriverWrapper
.
Then there's no need for additional registration.
Hi,
Latest version of jts driver on maven is 2.2.1
This references a postgis-jdbc version 2.1.0 in the pom file.
But 2.1.0 doesn't exist because it's an org.postigs not net.postgis
So sbt (don't know about others) is failing because it's looking for transitive dependency to net.postgis v 2.1.0 instead of org.postgis 2.1.0
The maven plugins and other supporting dependencies explicitly declared in the maven projects should be updated to latest versions.
The maven enforcer plugin should be added to the top-level aggregator project with some initial rules to force the usage of recent maven versions that are known to work fine for building the codebase.
ServerTest test class throws an error:
org.postgresql.util.PSQLException: ERROR: function astext(geometry) does not exist
This error only occurs when the testWithDatabase flag is true in the build. When the flag is set to false, no testing against a database occurs. Currently the flag is set to false by default, so the error does not occur and the running the testsuite is fine.
Apologies in advance, as I'm not 100% sure this is an issue with JDBC driver, just that I'm seeing an inconsistency with two almost identical projects... One works, the other doesn't, and the difference seems to come down to how JPA Entities with included JTS member types are being saved.
I'm getting the following error:
Exception Description: The type [class org.locationtech.jts.geom.Point] for the attribute [point] on the entity class [class com.adspore.Location] is not a valid type for a serialized mapping. The attribute type must implement the Serializable interface.
Both record types (working & not) include the implements Serializable interface.
Environment: Apache-TomEE-plus-7.1.1
lib/ directory includes: postgis-jdbc-2.3.0, postgis-jdbc-jtsparser-2.3.0, postgresql-9.4.1208.jre7
The two examples are identical (as near as I can determine), same dependencies in POM, same persistence.xml (tree location and content identical except for persistence unit name and class names). Further digging, both projects set to same JDK version and libraries.
In the working example, I added JTS Point elements to the TomEE example code in the 'tomee/examples/moviefun' project. Changed the JPA provider type to Eclipselink, added the same org.locationtech.jts dependencies to the POM, and everything works fine.
Thoughts? Where is the serialization of JTS types supposed to occur?
Any help would be greatly appreciated.
DD
persistence.xml
<?xml version="1.0" encoding="UTF-8"?> <persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"> <persistence-unit name="tb"> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider> <jta-data-source>TrialBalloon</jta-data-source> <class>com.adspore.Location</class> <properties> <property name="eclipselink.ddl-generation" value="drop-and-create-tables" /> </properties> </persistence-unit> </persistence>
Datasource Configuration in tomee.xml:
<Resource id="TrialBalloon" type="javax.sql.DataSource"> jdbcDriver=org.postgis.jts.JtsGisWrapper jdbcUrl=jdbc:postgresql_JTS://localhost:5432/trialballoon userName=junit password=junit jtaManaged=true </Resource>
The latest version of postgis bindings (2023.1.0) contains very vulnerable dependency.
Can it be updated to major version?
https://mvnrepository.com/artifact/net.postgis/postgis-jdbc/2023.1.0
Thank in advance!
The PostGIS Java2D implementation of points as GeneralPath accordingly to the Javadoc is: "Points thus are translated into MoveTo() followed by a closePath."
I've tested various methods.The point is drawn when the GeneralPath has a lineTo() to the same coordinates instead closePath() (as described below: "Maybe we need a LineTo() to the same coordinages instead.")
Perhaps someone can correct it :-)
Thanks
Hey,
Please prepare the result jars/maven modules postgres-jdbc and postgis-geometry for use in Java Platform Module System (JPMS).
With version 2.5.0 the jars are no longer usable in projects that JPMS use.
This was done with this step:
#79 Decoupled geometry and encoder/decoder from postgres-jdbc
Because we have now to jars/JPMS modules, who use the same package path.
a) Migrate to JPMS modules or add Automatic-Module-Name
b) Solve shared package problem
c) may solve #32 repackage classes as net.postgis instead of org.postgis
PostgreSQL JDBC Driver with versions before 42.7.2, 42.6.1, 42.5.5, 42.4.4, 42.3.9, and 42.2.8 are affected.
The Debian FTP master reviewing the recent postgis-java Debian package upload commented that the license headers need to use the correct LGPL2.1+ template.
Most suggest that it's LGPL-2.1-only having leaving out the ', or (at your option) any later version`. For example:
/*
* DriverWrapperAutoprobe.java
*
* PostGIS extension for PostgreSQL JDBC driver - Wrapper utility class
*
* (C) 2005 Markus Schaber, [email protected]
*
* This library is free software; you can redistribute it and/or modify it under
* the terms of the GNU Lesser General Public License as published by the Free
* Software Foundation, either version 2.1 of the License.
*
* This library is distributed in the hope that it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
* FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more
* details.
*
* You should have received a copy of the GNU Lesser General Public License
* along with this library; if not, write to the Free Software Foundation, Inc.,
* 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA or visit the web at
* http://www.gnu.org.
*
*/
The correct LGPL-2.1+ template is:
/*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
If the postgis-java source is not licensed under the LGPL-2.1+ (or later versions) this needs to be documented. The license referenced from the pom.xml
(lgpl-2.1.txt) is LGPL-2.1+ not LGPL-2.1 (only).
A minimally acceptable build system will run a test harness.
A minimally acceptable codebase will have tests for said test harness.
Version ranges may be causing some maven plugins and other tools such as sbt to fail with transitive dependency resolution. It's also often considered bad practice in some circles to use version ranges and other non-deterministic artifact resolution mechanisms within maven.
Write a small program to take a specified .jar plus a specified Postgres database, and make a collection of function calls to it. Please note this idea appeared while testing the OSGeo-Live, using OpenJDK 7, PostgreSQL 9.4 and PostGIS 2.2 under LUbuntu 1404. An initial version should work in that environment.
When using JTS driver version, if ResultsSet contains POLYGON EMPTY
library is throwing Exception:
java.sql.SQLException: Error parsing SQL data:java.lang.NegativeArraySizeException: -1
at net.postgis.jdbc.jts.JtsGeometry.geomFromString(JtsGeometry.java:108)
at net.postgis.jdbc.jts.JtsGeometry.setValue(JtsGeometry.java:83)
at org.postgresql.jdbc.PgConnection.getObject(PgConnection.java:654)
at org.postgresql.jdbc.PgResultSet.getObject(PgResultSet.java:3714)
Example query:
select ST_GeomFromText('POLYGON EMPTY')
I've added a PR with a couple of failing test cases ( #86 ) that details this problem.
The problems were discovered due to a line in the following format:
prep.setObject(6, new PGgeometryLW(GeometryBuilder.geomFromString("SRID=4326;MULTIPOLYGON EMPTY")));
which, when combined with "type-safe" columns (ie <column> geometry(MultiPolygon, 4326) NOT NULL
) caused the driver to throw exceptions.
See
https://lists.osgeo.org/pipermail/postgis-devel/2015-June/025006.html
Better not commit anything in here until the copy in postgis repository is removed...
Is there any plan to support POLYHEDRALSURFACE geometry types?
Originally posted by dannyooi July 19, 2021
I'm working on a project where I need to use this library to parse org.locationtech.jts.geom.Geometry
to JtsGeometry
and vice versa.
However, I face some errors when I try to use some of the methods:
java.lang.NoSuchMethodError: org.locationtech.jts.geom.Polygon.getExteriorRing()Lorg/locationtech/jts/geom/LineString;
at org.postgis.jts.JtsBinaryWriter.estimatePolygon(JtsBinaryWriter.java:357)
at org.postgis.jts.JtsBinaryWriter.estimateBytes(JtsBinaryWriter.java:296)
at org.postgis.jts.JtsBinaryWriter.writeBinary(JtsBinaryWriter.java:106)
at org.postgis.jts.JtsBinaryWriter.writeBinary(JtsBinaryWriter.java:113)
I found that the root cause of the issue is because the version of jts-core
is not up to date.
As of current version publish in Maven it is using jts-core:1.16.1
.
Your latest code is using 1.18.1
, but I can't find any latest publish in Maven repository.
May I know is there a plan to officially publish the latest version soon?
Currently the jdbc module has dependencies on java.awt in org.postgis.java2d
As of Java9 / Project jigsaw these will be part of a desktop module and may not be available server-side. Would it be possible to break this dependency out? If anybody is using it, perhaps to a different project?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.