Seeking Guidance on Contributing to OSGeo

Nishant · October 6, 2024, 8:46am

I am Nishant Bansal, a student with a background in data structures and algorithms (primarily in C++), and this would be my first time diving into C++ development for a larger project. I am eager to contribute to open-source projects, and I would greatly appreciate your guidance as I get started.

Could you kindly guide me on the following:

Repository Exploration: Which repository or part of the project should I focus on initially to get a better understanding of its structure and workings?
Contribution Opportunities: Are there specific components or issues that would be suitable for someone just starting to contribute? I’m eager to help in any way I can and would appreciate suggestions on where to begin.
Prior Knowledge: What specific concepts or technologies should I be familiar with before diving deeper? For example, are there any particular algorithms, libraries, or tools that are important to understand in order to contribute effectively?

Since this is my first time contributing to a C++ development project, I would appreciate any advice or resources you can provide to help me get up to speed. I’m enthusiastic about learning and contributing to the project.

Thank you for your time and support.

Best regards,
Nishant Bansal

robe · October 6, 2024, 11:22pm

First you have to decide on which projects of OSGeo interest you.

You can find a list of projects here - Projects Archive - OSGeo
Note that although all these projects are part of OSGeo, each has its own repository and website.

Are you planning to submit via Google Summer of Code or just on your own?

pgRouting for example is a C++ project that is involved in Google Summer of Code (GSOC) each year. Not all projects are and not all projects are equipped to handle students. This is not to say they wouldn’t welcome new developers, just that they are not used to having new developers.

If you are interested in pgRouting development, you’ll want to join Pgrouting developers - OSGeo Discourse and introduce yourself and your interests as detailed in About the pgrouting-dev category.

pgRouting also has an intro for GSOC students which is useful even if you want to get involved separate from GSOC. We have an ideas page and prior projects people have done listed here - Google Summer of Code · pgRouting/pgrouting Wiki · GitHub.

GRASS is another project that gets involved yearly with GSOC so is a good comforting place for new developer. To get involved with grass, join the developer group and introduce yourself as detailed in About the GRASS GIS developer category, also check out their page on contributing - Contribute

You should also check out the osgeo GSOC 2024 page which lists other projects that were involved in 2024 and some projects mentored - Google Summer of Code 2024 Ideas - OSGeo

annakrat · October 7, 2024, 2:20pm

Thanks @robe for introducing GRASS as well. Nishant, GRASS GIS is mostly C and Python (although we have several tools in C++). Here are two issues you could try to tackle if you want:

github.com/OSGeo/grass

[Feat] Add JSON output for columns in v.info

opened 05:02PM - 23 Aug 24 UTC

wenzeslaus

enhancement good first issue C

**Is your feature request related to a problem? Please describe.** The use of… _c_ flag for _v.info_ should produce JSON with `format=json`: ```bash grass --tmp-mapset ~/grassdata/nc_spm_08_grass7/ --exec v.info roadsmajor format=json -c ``` **Describe the solution you'd like** JSON output which contains column names and metadata for these columns. Type is already in the current output, but there is more what could be included: other types of types (e.g., C versus SQL: [db_sqltype_to_Ctype](https://grass.osgeo.org/programming8/sqlCtype_8c.html#a1c02fe09d3c3d7632e4498494f3a1efc)) or some info on whether the column represents a number or whether it needs to be quoted in SQL (e.g., #1110). **Describe alternatives you've considered** The output could be a dictionary (mapping) or a list. In any case, the format should be extensible so more info can be included in the future. If a single column is a dictionary, then there is no problem with extending that. The question is if the list of columns should be in a dictionary. Taking route of maximum flexibility: ```json { "columns": [ { "name": "cat", "sql_type": "INTEGER", }, { "name": "MAJORRDS_", "sql_type": "DOUBLE PRECISION", } ] } ``` Flexible only for the individual columns (simpler, but (perhaps?) less common list as a first level): ```json [ { "name": "cat", "sql_type": "INTEGER", }, { "name": "MAJORRDS_", "sql_type": "DOUBLE PRECISION", } ] ``` Shortest possible: ```json [ { "name": "cat", "type": "INTEGER", }, { "name": "MAJORRDS_", "type": "DOUBLE PRECISION", } ] ``` I don't think we should do this: ```json { "names": ["cat", "MAJORRDS_"], "types": ["INTEGER", "DOUBLE PRECISION"] } ``` **Additional context** The output should be similar, compatible and/or in sync with _v.db.select_: ```sh $ grass --tmp-mapset ~/grassdata/nc_spm_08_grass7/ --exec v.db.select roadsmajor format=json | jq .info ``` ```json { "columns": [ { "name": "cat", "sql_type": "INTEGER", "is_number": true }, { "name": "MAJORRDS_", "sql_type": "DOUBLE PRECISION", "is_number": true }, { "name": "ROAD_NAME", "sql_type": "CHARACTER", "is_number": false }, { "name": "MULTILANE", "sql_type": "CHARACTER", "is_number": false }, { "name": "PROPYEAR", "sql_type": "INTEGER", "is_number": true }, { "name": "OBJECTID", "sql_type": "INTEGER", "is_number": true }, { "name": "SHAPE_LEN", "sql_type": "DOUBLE PRECISION", "is_number": true } ] } ``` Currently, the following is produced with the _c_ flag: ``` Displaying column types/names for database connection of layer <1>: INTEGER|cat DOUBLE PRECISION|MAJORRDS_ CHARACTER|ROAD_NAME CHARACTER|MULTILANE INTEGER|PROPYEAR INTEGER|OBJECTID DOUBLE PRECISION|SHAPE_LEN ``` (The `Displaying column ...` text goes to stderr and should not be produced for JSON.) We do have tools which give lists, e.g., `g.gisenv get="GISDBASE,LOCATION_NAME,MAPSET" sep="comma"`, but once the output is more complex, list on the first level seems too limiting - I included also info about the columns to _v.db.select_ so that the full information about the type is preserved and can be used to, e.g., create a derived table.

github.com/OSGeo/grass

[Feat] Add JSON output to r.colors.out

opened 05:58PM - 27 Mar 24 UTC

petrasovaa

enhancement gsoc

Add JSON output for easy parsing of r.colors.out output. **Describe the solut…ion you'd like** Adding option format, it would be something like format=plain for the current output format and format=json for the JSON output. There is a newly added parson library to GRASS (https://github.com/OSGeo/grass/pull/3028), so it should be used here. See also discussion in https://github.com/OSGeo/grass/discussions/3019. A test should be included. A possible JSON layout could be: ``` [ { "value": 0, "red": 255, "green": 0, "blue": 0 }, { "value": 1, "red": 0, "green": 255, "blue": 0 }, { "value": 2, "red": 0, "green": 0, "blue": 255 } ] ```