<div dir="ltr">Oh Alright. Thanks a lot for the detailed breakup. I think it was my mistake i wasn't clear at all. I just wanted to know how we are designing the site are there designers involved on the website front. <div>
<br></div><div>Secondly my interest is mainly on the backend, POSTGIS, Routing Algos on top of it etc... Now that i see there are quite a few components. What I'll do is go thru the components and see what interests me and start picking up really small tasks on those components.</div>
<div><br></div><div>Cheers,</div><div>Akash A</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 9, 2013 at 9:31 PM, Serge Wroclawski <span dir="ltr"><<a href="mailto:emacsen@gmail.com" target="_blank">emacsen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Akash,<br>
<br>
It's a bit more complicated than that- and this really should be<br>
better documented (or if it- easier to find).<br>
<br>
You can think of OSM as a series of components which fit in together<br>
and then each have their own purpose.<br>
<br>
At the bottom, the lowest level, there is the Postgis database, with<br>
the API schema.<br>
<br>
Then on top of that is the website, sometimes called "the rails port".<br>
It's written in Ruby on Rails and handles all the user action on<br>
<a href="http://osm.org" target="_blank">osm.org</a> and has code for all the OSM editing API (commonly just called<br>
"the API").<br>
<br>
>From there, the rest of the systems are more or less decoupled.<br>
<br>
cgimap is a program that handles the most performance sensitive API<br>
calls. It's written in C with an eye towards speed (vs the website<br>
itself, which is in rails).<br>
<br>
Then there's the render system. That deserves its own email, but<br>
essentially it's a separate database, and a software stack of it own.<br>
<br>
Then there's the geocoder, nominatim. It also deserves its own email,<br>
and it is also a separate database and software stack.<br>
<br>
Then there's the editors. Some of them, like iD and Potlach, are web<br>
based, so they live in the website, as far as the user is concerned,<br>
but are maintained by different teams of people. Other editors (like<br>
Josm) run on the desktop, or they run on mobile phones. All the<br>
editors talk to the API.<br>
<br>
<br>
So when you say you want to work on "interaction"- folks are assuming<br>
you mean the website, but they're not sure if you don't mean one of<br>
the editors.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Serge<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Cheers,<div>Akash A</div>
</div>