OSGeo - User contributions [en]

GSoC 2022 Node.js for ZOO-Project

2022-07-02T08:44:00Z

Mmomtchev: /* ZOO-Project GSoC 2022 Proposal by @mmomtchev */

= ZOO-Project GSoC 2022 Contribution by @mmomtchev =

== Adding Node.js support for service implementation to be run from the ZOO-Kernel ==



= Abstract =

The ZOO-Project is a solid WPS server able to handle services implemented in various different programming languages. The existing <code>ZOO-Kernel</code> supports C, C++, and JS implementations with the SpiderMonkey engine. With this project, the objective is to add support for NodeJS implementation of the <code>ZOO-Kernel</code>.

Mentors: Gérald Fenoy, Aditi Sawant, Rajat Shinde


= Contributor Personal Details =

Momtchil Momtchev [mailto:momtchil@momtchev.com momtchil@momtchev.com], France +33611640937 https://github.com/mmomtchev https://twitter.com/mmomtchev https://mmomtchev.medium.com

Graduated from the Université des Sciences et des Technologies de Lille with a French DEA in Computer Science (Master’s equivalent)

Currently unemployed and looking for job in open-source

First time applicant to GSoC

Co-author and current maintainer of the Node.js bindings for GDAL (https://github.com/mmomtchev/node-gdal-async)

Author of the React bindings for OpenLayers (https://github.com/mmomtchev/rlayers)

Author of the Node.js bindings for ExprTk (https://github.com/mmomtchev/exprtk.js)

Occasional Node.js and GDAL contributor

Author of numerous smaller packages and tools (https://www.npmjs.com/~mmomtchev)

Expert C/C++ and JS/TS engineer with Linux, macOS and Windows experience


= Existing Software =

Currently ZOO-Project supports JS services through the embedded version of the SpiderMonkey engine. It is linked as a shared library and every invocation of a service results in a separate instance of the SpiderMonkey engine.


= Proposed Solution =

The current latest LTS version of Node.js, Node.js 16.x, is to be embedded in the <code>ZOO-Kernel</code> executable following the same architecture as SpiderMonkey.

It is worth noting that the next LTS version of Node.js, Node.js 18 is scheduled to be released during the GSoC timeline. As this version is not expected to replace the 16.x as recommended version until October 2022, it is believed that Node.js 16.x remains the safer choice.

Node.js supports being built as a shared library since version 12.x. This feature is used by the Electron project which is its main maintainer. It allows the JS runtime to be loaded inside the address space of the calling program and to both call JS functions from the native code and expose native functions to the JS code.

There are several different interfaces available for interacting with the Node.js runtime:

* By calling raw internal V8 and Node.js methods which are usually not stable across different versions
* By using the [https://github.com/nodejs/nan NAN C++ API] C++ which is stable at the source level across different versions
* By using the [https://nodejs.org/api/n-api.html Node C N-API] which is stable at the binary level across different versions
* By using the [https://github.com/nodejs/node-addon-api Node Addon C++ API] which is stable at the binary level across different versions

Of these methods, the Node C N-API seems to be the best suited for ZOO-Project as it is binary stable across different Node.js versions and it does not require C++.

It should be noted that while these APIs/ABIs are usually meant to be used by native addons that are loaded by the main Node.js process as a shared library, they are also perfectly usable in the opposite direction - ie when Node.js is loaded as a shared library by a 3rd party process.

Node.js supports running multiple V8 isolates, each with a separate main thread, offering a completely separate execution environment to each JS instance.

These separate instances have separate event loops but can share the same worker thread pool.

This mode of embedding Node.js matches most closely the existing JS architecture based on SpiderMonkey. It is also the preferred mode for embedding Node.js.

The following alternatives have also been considered: * Run every instance of a service in a separate, external, Node.js process This mode will have a more expensive startup and will present unique challenges when implementing the various ZOO-Project routines which will have to communicate with the <code>ZOO-Kernel</code> by some external mechanism - such as RabbitMQ. * Run all instances of a service in a single shared environment This mode offers the potentially best performance but it imposes upon the end-user to use very correctly the Node.js asynchronous mechanisms - failing to do so will result in latency spikes and possibly dropped connections.

Rebuilding <code>libnode</code> as part of the <code>ZOO-Project</code> build system is considered to be out of the scope of the current project - just as the current SpiderMonkey shared library is expected to be provided by the end-user, so will be <code>libnode</code> which is already carried by some major Linux distributions - Ubuntu being one of them.


= Testing methodology =

<code>ZOO-Project</code> already has an existing testing framework which includes the SpiderMonkey services. The new Node.js implementation is to be able to run those services passing the existing SpiderMonkey tests without modifying the services code.

Additionally, an <code>AddressSanitizer</code> build, currently absent from <code>ZOO-Project</code> is one of the stretch goals of the proposal.


= Proposal Timeline =

I am fully committed to working on this project during this time period and I am free of any other professional obligations.


== Before June 13 ==

* To familiarize myself completely with ZOO-Project functionality and architecture.
* To experiment with using <code>libnode</code>, the embedded version of NodeJS and test the compatibility between the packaged <code>libnode</code> by the Linux distributions and the existing Node.js native addons

== June 13 - July 25 ==


=== June 13 - June 17 ===

* Implement the creation of the <code>libnode</code> context in <code>service_internal_nodejs.c</code> to be called from <code>zoo_service_loader.c:loadServiceAndRun()</code>
* Include <code>libnode</code> in the <code>ZOO-Kernel</code> build and link against it in the official Dockerfile
* Use a dummy static JS method


=== June 20 - June 24 ===

* Test building with the versions included Ubuntu, Debian, CentOS and Fedora


=== June 27 - July 1 ===

* Implement <code>ZOORequest</code>, <code>ZOOTranslate</code>, <code>ZOOUpdateStatus</code> and <code>alert</code> using Node N-API


=== July 4 - July 8 ===

* Implement the object and the array transforms using Node N-API


=== July 11 - July 15 ===

* Load the existing 3rd party code - mostly <code>proj4js</code> into the environment


=== July 18 - July 22 ===

* Spare week for testing and debugging


== July 25 - July 29 ==

* Phase 1 evaluation: the existing SpiderMonkey unit tests should be passing on Node.js at this point


== July 29 - September 4 ==

Stretch goals


=== August 1 - August 5 ===

* Add builtin Node.js GDAL support
* Allow JS services to use <code>gdal-async</code> out of the box
* Reimplement the GDAL profile C++ service in JS as an example


=== August 8 - August 12 ===

* Create and automate an <code>AddressSanitizer</code> build to be run in continuous integration


=== August 15 - August 19 ===

* Allow services to request to be executed in a single-instance mode by providing an <code>async</code> function as entry point


=== August 22 - August 26 ===

* Add snapshot support to <code>libnode</code> - it could benefit from having the same V8 snapshot support as the Node.js main executable. V8 supports creating and restoring snapshots of a JS heap - this feature is used by Node.js to speed-up the initial loading of the JS class library - instead of compiling it at every process startup, it is compiled and initialized once during the build of the Node.js executable and then the JS heap is saved in a snapshot to be reused when launching Node.js. Currently, this feature is not readily available when using <code>libnode</code>. Electron re-implements it on its own. This is to be submitted for merging back in Node.js.


=== August 29 - September 2 ===

* Spare week for testing and debugging


== After September 4 ==

* Phase 2 evaluation

Google Summer of Code 2022 Accepted

2022-06-12T20:55:50Z

Mmomtchev: replace the Node.js for Zoo-Project link

<center>
[[Image:GSoC2016Logo.jpg|400px|link=https://developers.google.com/open-source/gsoc/]] @ 
[[Image:Osgeo-logo.png|300px|link=http://www.osgeo.org]]
</center>

* Back to the main OSGeo [[Google Summer of Code 2022]] @ OSGeo wiki page.

== Accepted Proposals ==

This year OSGeo accepted 7 contributors working on the following [https://summerofcode.withgoogle.com/programs/2022/organizations/osgeo-open-source-geospatial-foundation projects]:

{|class="wikitable sortable" border="2" cellspacing="0" cellpadding="4" rules="all" style="margin:1em 1em 1em 0; border:solid 1px #AAAAAA; border-collapse:collapse; background-color:#D7E3D1; font-size:95%; empty-cells:show;"
|'''Project Logo'''
|'''Community'''
|'''Project'''
|'''Student'''
|'''1st mentor'''
|'''2nd mentor'''
|'''Other Mentors'''
|'''Wiki page'''
|'''Repository'''
|-
|[[Image:ZOO-Project-mini.png|40px|center]]
|ZOO-Project
|ZOO-Project - Adding Cesium support within MapMint
|[[User:Bsolanki|Bhupendra Solanki]]
|[[User:Aditi_Sawant|Aditi Sawant]]
|[[User:Djay|Gérald Fenoy]]
|[[User:RajatShinde|Rajat Shinde]]
|https://github.com/bhupendra1324/mapmint/wiki/ZOO-Project---Adding-Cesium-support-within-MapMint
|https://github.com/bhupendra1324/mapmint
|-
|-
|[[Image:Pgrouting-logo.png|40px|center]]
|pgRouting
|Osgeo[Pgrouting] : Add Google OR Tools functionality in Vrprouting
|[[User:RisingKnight|Manas]]
|[[User:Krashish8|Ashish Kumar]]
|[[User:Cvvergara|Celia Virginia Vergara Castillo]]
|
|https://github.com/pgRouting/pgrouting/wiki/Add-Google-OR-Tools-functionality-in-vrpRouting
|https://github.com/Manas23601/GSoC-pgRouting?organization=Manas23601&organization=Manas23601
|-
|-
|[[Image:ZOO-Project-mini.png|40px|center]]
|ZOO-Project
|Adding Node.js support for service implementation to the ZOO-Kernel
|[[User:Mmomtchev|Momtchil Momtchev]]
|[[User:RajatShinde|Rajat Shinde]]
|[[User:Djay|Gérald Fenoy]]
|[[User:Aditi_Sawant|Aditi Sawant]]
|[[GSoC 2022 Node.js for ZOO-Project]]
|https://github.com/mmomtchev/ZOO-Project
|-
|-
|[[Image:Pgrouting-logo.png|40px|center]]
|pgRouting
|Implementing hawick_circuits algorithm from Boost Graph Library to pgRouting
|[[User:Nitish|Nitish Chauhan]]
|[[User:Veenits123|Veenit Kumar]]
|[[User:Danielkastl|Daniel Kastl]]
|
|https://github.com/pgRouting/pgrouting/wiki/GSoC-2022-Implementing-hawick_circuits-algorithm-from-Boost-Graph-Library-to-pgRouting
|https://github.com/nitishchauhan0022/GSoC-pgRouting
|-
|-
|[[Image:ZOO-Project-mini.png|40px|center]]
|ZOO-Project
|Integrating ZOO-services with QGIS
|[[User:Sdhoundiyal|Sandeepan Dhoundiyal]]
|[[User:Djay|Gérald Fenoy]]
|[[User:Aditi_Sawant|Aditi Sawant]]
|[[User:RajatShinde|Rajat Shinde]]
|https://github.com/sdhoundiyal/GSoC_ZOO-Project/wiki/Integrating-ZOO-Services-with-QGIS
|https://github.com/sdhoundiyal/GSoC_ZOO-Project
|-
|-
|[[Image:Pgrouting-logo.png|40px|center]]
|pgRouting
|Implementing Various Functionalities to Calculate Important Graph Metrics in pgRouting
|[[User:sbdtu5498|Sanskar Bhushan]]
|[[User:Cvvergara|Celia Virginia Vergara Castillo]]
|[[User:Krashish8|Ashish Kumar]]
|
|https://github.com/pgRouting/pgrouting/wiki/GSoC-2022-Implementing-Various-Functionalities-to-Calculate-Important-Graph-Metrics-in-pgRouting
|https://github.com/sbdtu5498/GSoC-pgRouting
|-
|-
|[[Image:Pgrouting-logo.png|40px|center]]
|pgRouting
|Implement Cuthill-Mckee Ordering Boost Graph Library Algorithm for pgRouting
|[[User:Shobhit|Shobhit Chaurasia]]
|[[User:Danielkastl|Daniel Kastl]]
|[[User:Veenits123|Veenit Kumar]]
|
|https://github.com/pgRouting/pgrouting/wiki/GSoC-2022-Implement-Cuthill-Mckee-Ordering-Algorithm-for-pgRouting-by-the-Boost-Graph-Library
|https://github.com/shobhit162/GSoC-pgRouting
|-

|}

[[Category:Google Summer of Code]]

GSoC 2022 Node.js for ZOO-Project

2022-06-12T20:54:26Z

Mmomtchev: Import the github markdown

= ZOO-Project GSoC 2022 Proposal by @mmomtchev =


== Adding Node.js support for service implementation to be run from the ZOO-Kernel ==


= Abstract =

The ZOO-Project is a solid WPS server able to handle services implemented in various different programming languages. The existing <code>ZOO-Kernel</code> supports C, C++, and JS implementations with the SpiderMonkey engine. With this project, the objective is to add support for NodeJS implementation of the <code>ZOO-Kernel</code>.

Mentors: Gérald Fenoy, Aditi Sawant, Rajat Shinde


= Contributor Personal Details =

Momtchil Momtchev [mailto:momtchil@momtchev.com momtchil@momtchev.com], France +33611640937 https://github.com/mmomtchev https://twitter.com/mmomtchev https://mmomtchev.medium.com

Graduated from the Université des Sciences et des Technologies de Lille with a French DEA in Computer Science (Master’s equivalent)

Currently unemployed and looking for job in open-source

First time applicant to GSoC

Co-author and current maintainer of the Node.js bindings for GDAL (https://github.com/mmomtchev/node-gdal-async)

Author of the React bindings for OpenLayers (https://github.com/mmomtchev/rlayers)

Author of the Node.js bindings for ExprTk (https://github.com/mmomtchev/exprtk.js)

Occasional Node.js and GDAL contributor

Author of numerous smaller packages and tools (https://www.npmjs.com/~mmomtchev)

Expert C/C++ and JS/TS engineer with Linux, macOS and Windows experience


= Existing Software =

Currently ZOO-Project supports JS services through the embedded version of the SpiderMonkey engine. It is linked as a shared library and every invocation of a service results in a separate instance of the SpiderMonkey engine.


= Proposed Solution =

The current latest LTS version of Node.js, Node.js 16.x, is to be embedded in the <code>ZOO-Kernel</code> executable following the same architecture as SpiderMonkey.

It is worth noting that the next LTS version of Node.js, Node.js 18 is scheduled to be released during the GSoC timeline. As this version is not expected to replace the 16.x as recommended version until October 2022, it is believed that Node.js 16.x remains the safer choice.

Node.js supports being built as a shared library since version 12.x. This feature is used by the Electron project which is its main maintainer. It allows the JS runtime to be loaded inside the address space of the calling program and to both call JS functions from the native code and expose native functions to the JS code.

There are several different interfaces available for interacting with the Node.js runtime:

* By calling raw internal V8 and Node.js methods which are usually not stable across different versions
* By using the [https://github.com/nodejs/nan NAN C++ API] C++ which is stable at the source level across different versions
* By using the [https://nodejs.org/api/n-api.html Node C N-API] which is stable at the binary level across different versions
* By using the [https://github.com/nodejs/node-addon-api Node Addon C++ API] which is stable at the binary level across different versions

Of these methods, the Node C N-API seems to be the best suited for ZOO-Project as it is binary stable across different Node.js versions and it does not require C++.

It should be noted that while these APIs/ABIs are usually meant to be used by native addons that are loaded by the main Node.js process as a shared library, they are also perfectly usable in the opposite direction - ie when Node.js is loaded as a shared library by a 3rd party process.

Node.js supports running multiple V8 isolates, each with a separate main thread, offering a completely separate execution environment to each JS instance.

These separate instances have separate event loops but can share the same worker thread pool.

This mode of embedding Node.js matches most closely the existing JS architecture based on SpiderMonkey. It is also the preferred mode for embedding Node.js.

The following alternatives have also been considered: * Run every instance of a service in a separate, external, Node.js process This mode will have a more expensive startup and will present unique challenges when implementing the various ZOO-Project routines which will have to communicate with the <code>ZOO-Kernel</code> by some external mechanism - such as RabbitMQ. * Run all instances of a service in a single shared environment This mode offers the potentially best performance but it imposes upon the end-user to use very correctly the Node.js asynchronous mechanisms - failing to do so will result in latency spikes and possibly dropped connections.

Rebuilding <code>libnode</code> as part of the <code>ZOO-Project</code> build system is considered to be out of the scope of the current project - just as the current SpiderMonkey shared library is expected to be provided by the end-user, so will be <code>libnode</code> which is already carried by some major Linux distributions - Ubuntu being one of them.


= Testing methodology =

<code>ZOO-Project</code> already has an existing testing framework which includes the SpiderMonkey services. The new Node.js implementation is to be able to run those services passing the existing SpiderMonkey tests without modifying the services code.

Additionally, an <code>AddressSanitizer</code> build, currently absent from <code>ZOO-Project</code> is one of the stretch goals of the proposal.


= Proposal Timeline =

I am fully committed to working on this project during this time period and I am free of any other professional obligations.


== Before June 13 ==

* To familiarize myself completely with ZOO-Project functionality and architecture.
* To experiment with using <code>libnode</code>, the embedded version of NodeJS and test the compatibility between the packaged <code>libnode</code> by the Linux distributions and the existing Node.js native addons

== June 13 - July 25 ==


=== June 13 - June 17 ===

* Implement the creation of the <code>libnode</code> context in <code>service_internal_nodejs.c</code> to be called from <code>zoo_service_loader.c:loadServiceAndRun()</code>
* Include <code>libnode</code> in the <code>ZOO-Kernel</code> build and link against it in the official Dockerfile
* Use a dummy static JS method


=== June 20 - June 24 ===

* Test building with the versions included Ubuntu, Debian, CentOS and Fedora


=== June 27 - July 1 ===

* Implement <code>ZOORequest</code>, <code>ZOOTranslate</code>, <code>ZOOUpdateStatus</code> and <code>alert</code> using Node N-API


=== July 4 - July 8 ===

* Implement the object and the array transforms using Node N-API


=== July 11 - July 15 ===

* Load the existing 3rd party code - mostly <code>proj4js</code> into the environment


=== July 18 - July 22 ===

* Spare week for testing and debugging


== July 25 - July 29 ==

* Phase 1 evaluation: the existing SpiderMonkey unit tests should be passing on Node.js at this point


== July 29 - September 4 ==

Stretch goals


=== August 1 - August 5 ===

* Add builtin Node.js GDAL support
* Allow JS services to use <code>gdal-async</code> out of the box
* Reimplement the GDAL profile C++ service in JS as an example


=== August 8 - August 12 ===

* Create and automate an <code>AddressSanitizer</code> build to be run in continuous integration


=== August 15 - August 19 ===

* Allow services to request to be executed in a single-instance mode by providing an <code>async</code> function as entry point


=== August 22 - August 26 ===

* Add snapshot support to <code>libnode</code> - it could benefit from having the same V8 snapshot support as the Node.js main executable. V8 supports creating and restoring snapshots of a JS heap - this feature is used by Node.js to speed-up the initial loading of the JS class library - instead of compiling it at every process startup, it is compiled and initialized once during the build of the Node.js executable and then the JS heap is saved in a snapshot to be reused when launching Node.js. Currently, this feature is not readily available when using <code>libnode</code>. Electron re-implements it on its own. This is to be submitted for merging back in Node.js.


=== August 29 - September 2 ===

* Spare week for testing and debugging


== After September 4 ==

* Phase 2 evaluation

User:Mmomtchev

2022-06-12T20:49:58Z

Mmomtchev:

{{OSGeo Member
|Name=Momtchil Momtchev
|JobTitle=Unemployed
|Company=
|Address=
|Country=France
|State=
|City=Paris
|Coordinate=48.820203, 2.364019
|LocalChapter=France
|Email=momtchil AT momtchev DOT com
|SocialMedia=https://github.com/mmomtchev
|Website=https://github.com/mmomtchev
|Photo=Mmomtchev.jpg
|Languages=English, French, Bulgarian, some Russian
|Info= .
* Contributor - [[GSoC 2022 Node.js for ZOO-Project]]
* Current maintainer the GDAL bindings for Node.js - https://github.com/mmomtchev/node-gdal-async
* Occasional GDAL contributor
* Author of the React components for OpenLayers - https://github.com/mmomtchev/rlayers
* Unemployed because of a huge judicial scandal
}}
{{OSGeo Experience
|User=Yes
|Committee=No
|Board=No
|Coder=Yes
|Translate=No
|PSC=No
|ExBoard=No
|Charter=No
|Chair=No
|SolKatz=No
|Committer=No
}}

Google Summer of Code 2022 Accepted

2022-06-10T21:19:37Z

Mmomtchev: Add mmomtchev's links

<center>
[[Image:GSoC2016Logo.jpg|400px|link=https://developers.google.com/open-source/gsoc/]] @ 
[[Image:Osgeo-logo.png|300px|link=http://www.osgeo.org]]
</center>

* Back to the main OSGeo [[Google Summer of Code 2022]] @ OSGeo wiki page.

== Accepted Proposals ==

This year OSGeo accepted 7 contributors working on the following [https://summerofcode.withgoogle.com/programs/2022/organizations/osgeo-open-source-geospatial-foundation projects]:

{|class="wikitable sortable" border="2" cellspacing="0" cellpadding="4" rules="all" style="margin:1em 1em 1em 0; border:solid 1px #AAAAAA; border-collapse:collapse; background-color:#D7E3D1; font-size:95%; empty-cells:show;"
|'''Project Logo'''
|'''Community'''
|'''Project'''
|'''Student'''
|'''1st mentor'''
|'''2nd mentor'''
|'''Other Mentors'''
|'''Wiki page'''
|'''Repository'''
|-
|[[Image:ZOO-Project-mini.png|40px|center]]
|ZOO-Project
|ZOO-Project - Adding Cesium support within MapMint
|Bhupendra Solanki
|[[User:Aditi_Sawant|Aditi Sawant]]
|[[User:Djay|Gérald Fenoy]]
|[[User:RajatShinde|Rajat Shinde]]
|https://github.com/bhupendra1324/mapmint/wiki/ZOO-Project---Adding-Cesium-support-within-MapMint
|https://github.com/bhupendra1324/mapmint
|-
|-
|[[Image:Pgrouting-logo.png|40px|center]]
|pgRouting
|Osgeo[Pgrouting] : Add Google OR Tools functionality in Vrprouting
|[[User:RisingKnight|Manas]]
|[[User:Krashish8|Ashish Kumar]]
|[[User:Cvvergara|Celia Virginia Vergara Castillo]]
|
|https://github.com/pgRouting/pgrouting/wiki/Add-Google-OR-Tools-functionality-in-vrpRouting
|https://github.com/Manas23601/GSoC-pgRouting?organization=Manas23601&organization=Manas23601
|-
|-
|[[Image:ZOO-Project-mini.png|40px|center]]
|ZOO-Project
|Adding Node.js support for service implementation to the ZOO-Kernel
|[[User:Mmomtchev|Momtchil Momtchev]]
|[[User:RajatShinde|Rajat Shinde]]
|[[User:Djay|Gérald Fenoy]]
|[[User:Aditi_Sawant|Aditi Sawant]]
|https://github.com/mmomtchev/mmomtchev/blob/master/ZOO-Project-mmomtchev-GSOC-2022.md
|https://github.com/mmomtchev/ZOO-Project
|-
|-
|[[Image:Pgrouting-logo.png|40px|center]]
|pgRouting
|Implementing hawick_circuits algorithm from Boost Graph Library to pgRouting
|[[User:Nitish|Nitish Chauhan]]
|[[User:Veenits123|Veenit Kumar]]
|[[User:Danielkastl|Daniel Kastl]]
|
|https://github.com/pgRouting/pgrouting/wiki/GSoC-2022-Implementing-hawick_circuits-algorithm-from-Boost-Graph-Library-to-pgRouting
|https://github.com/nitishchauhan0022/GSoC-pgRouting
|-
|-
|[[Image:ZOO-Project-mini.png|40px|center]]
|ZOO-Project
|Integrating ZOO-services with QGIS
|[[User:Sdhoundiyal|Sandeepan Dhoundiyal]]
|[[User:Djay|Gérald Fenoy]]
|[[User:Aditi_Sawant|Aditi Sawant]]
|[[User:RajatShinde|Rajat Shinde]]
|https://github.com/sdhoundiyal/GSoC_ZOO-Project/wiki/Integrating-ZOO-Services-with-QGIS
|https://github.com/sdhoundiyal/GSoC_ZOO-Project
|-
|-
|[[Image:Pgrouting-logo.png|40px|center]]
|pgRouting
|Implementing Various Functionalities to Calculate Important Graph Metrics in pgRouting
|Sanskar Bhushan
|[[User:Cvvergara|Celia Virginia Vergara Castillo]]
|[[User:Krashish8|Ashish Kumar]]
|
|
|
|-
|-
|[[Image:Pgrouting-logo.png|40px|center]]
|pgRouting
|Implement Cuthill-Mckee Ordering Boost Graph Library Algorithm for pgRouting
|[[User:Shobhit|Shobhit Chaurasia]]
|[[User:Danielkastl|Daniel Kastl]]
|[[User:Veenits123|Veenit Kumar]]
|
|https://github.com/pgRouting/pgrouting/wiki/GSoC-2022-Implement-Cuthill-Mckee-Ordering-Algorithm-for-pgRouting-by-the-Boost-Graph-Library
|https://github.com/shobhit162/GSoC-pgRouting
|-

|}

[[Category:Google Summer of Code]]

User:Mmomtchev

2022-05-27T21:03:03Z

Mmomtchev: first version

{{OSGeo Member
|Name=Momtchil Momtchev
|JobTitle=Unemployed
|Company=
|Address=
|Country=France
|State=
|City=Paris
|Coordinate=48.820203, 2.364019
|LocalChapter=France
|Email=momtchil AT momtchev DOT com
|SocialMedia=https://github.com/mmomtchev
|Website=https://github.com/mmomtchev
|Photo=Mmomtchev.jpg
|Languages=English, French, Bulgarian, some Russian
|Info= .
* GSoC 2022 contributor for ZOO-Project
* Current maintainer the GDAL bindings for Node.js - https://github.com/mmomtchev/node-gdal-async
* Occasional GDAL contributor
* Author of the React components for OpenLayers - https://github.com/mmomtchev/rlayers
* Unemployed because of a huge judicial scandal
}}
{{OSGeo Experience
|User=Yes
|Committee=No
|Board=No
|Coder=Yes
|Translate=No
|PSC=No
|ExBoard=No
|Charter=No
|Chair=No
|SolKatz=No
|Committer=No
}}

File:Mmomtchev.jpg

2022-05-27T20:53:05Z

Mmomtchev:

Momtchil Momtchev