Hello everyone,
I am a Portuguese student, currently studying Information Systems and Computer Engineering at IST (Instituto Superior Técnico) in Lisbon [http://www.ist.utl.pt/en/].
I admit that I did not know your project prior to the GSoC program but your project caught my attention, it’s an interesting field. I’ve been lurking around for a couple of days and I’m really enjoying your project.
The Geospatial project ideas seem really interesting and would be a great way to apply my JavaScript skills to a real project. Should I start focusing on a single idea already? Vector Data Visualization sounds fun and I would like to pick up one of these projects depending on interest shown by others…
So far I’ve forked your repo on GitHub and set up Eclipse for development, I’m wondering how can I strengthen my future project proposal, what can I start doing? Are there any “easy/medium” difficulty bugs or cleanup I could do to get more familiar with the code base? I’m reading Cesium’s Architecture at the moment. I would appreciate some tips.
Best regards,
André Nunes
Hi André,
Thanks for the interest. Sounds like you already made it through the Contributor’s Guide so you are off to a good start. Next, check out the references in the Ideas List for the projects that most interest you. Then I suggest discussing them on this mailing list or by emailing the mentor. As for bugs to get started, check out the GitHub issues and see what interests you. #278 sounds pretty easy even though it is not core Cesium.
Regards,
Patrick
Thanks for the tip, as you’ve probably noticed I’ve started looking into issue #89 but I’ll look into #278 as well.
I have some questions about good “commit etiquette”, should I create a branch every time I go on solving an issue?
How often should I commit? Every time I change a file? My idea is that if the changes are related, like when solving a single issue, it’s ok to commit them all together, but I might be wrong. Please advice.
Thanks.
Terça-feira, 16 de Abril de 2013 19:54:56 UTC+1, Patrick Cozzi escreveu:
Yes, generally each feature and each bug gets its own branch, because Git makes it simple for lots of branches to be created and deleted rapidly. How often you commit to your new branch is up to you, but personally I try to commit something for every few hours of work, or for each distinct portion of a set of features I’m working on. You can put as many files into a single commit as needed, but think about a person (maybe yourself 6 months from now when you’ve forgotten what you were doing) who wants to review or study what you changed. They don’t want to see the changes divided by filenames, that’s already on disk. They want to see a set of files that all changed for the same reason, with the commit message describing that reason.
–Ed.
I’m interested in the GML project but I wonder how to go from an hundred pages specification to an implementation plan Probabily looking for cookbooks and examples of sucessful implementations.
I guess that going through the schema and enconding rules would be a good start…
Any tips on how to start preparing a timeline for this project?
Quarta-feira, 17 de Abril de 2013 15:42:38 UTC+1, Ed Mackey escreveu:
To be honest, GML is probably one of the most difficult things to implement on our ideas page. I would want to see a very thorough and well-thought out strategy before selecting someone to implement it, and the person would need to have a solid resume showing he could accomplish such a large task. Meanwhile, KML is an official OGC standard and a much smaller subset of GML is part of it. If you’re interested in GML then it might be better to start off by implementing KML first, which is much smaller. Check out this link for the official OGC standard: http://www.opengeospatial.org/standards/kml
So just to be clear, I’m not against anyone working on GML, but I would rather a smaller project be implemented successfully than a larger project only get half-done.
If you guys didn’t already see, instead of doing all of GML, we can just do the OpenGIS GML Simple Features Profile, which I believe is much easier, but I haven’t taken a close look myself. This profile is useful alone because it is what is returned by WFS.
Patrick
with GML I would also recommend not to try to implement
the whole standard (where is this used in the wild anyway?)
but rather only the subset that is used for KML or WFS
I agree with Matt, I think it will be better to invest in a project like KML that can be completed during the Summer and that will serve as a stepping stone for further projects, not only for Cesium, but for me as well.
I need some points on where to start, other than researching into KML spec, I guess I should look into Cesium API, how it draws from data formats and how to extend it to support KML.
Any pointers in the right direction?
Cheers.
Sexta-feira, 19 de Abril de 2013 6:22:36 UTC+1, Christian Ledermann escreveu:
I’m actually in the process of refactoring a bunch of our code to make this easier to do from an architecture standpoint. So there’s no “plug-in point” yet for hooking in KML, but there will be soon. That being said, ultimately, you’ll be dealing with things at the DynamicScene level. The short version is that you’ll be implementing a KmlDataSource which create’s a bunch of DynamicObject instances (will probably be renamed) that represent the various KML features. Part of this effort will also involve creating a list of KML features that are currently not supported in Cesium (for example, extrusions).
That’s the “base” goal for KML support. Depending on how that first step goes, we’ll have some options on where to go from there.
Do you expect it to be ready in time or during the GSoC?
If help is needed let me know. Maybe the refactoring could be included in the KML project idea? It’s up to you.
At the moment I’m working on fixing some issues from GitHub but I’ll soon start looking into the KML spec to start composing that list of features. It would be good to have that list ready in time for coding season.
Sexta-feira, 19 de Abril de 2013 14:44:05 UTC+1, Matthew Amato escreveu:
Hello,
I’ve made a project proposal and would love to hear some feedback about it.
It’s still a rough draft, I want to implement KML (with GML in the horizon), from what I’ve read here it would be hard to complete GML during the Summer so adding KML which is is a small subset of GML is more realistic.
Matt, I would like to know more about this “plug-in point” you are working on as I believe it will be crucial for this project.
Thanks.
Sábado, 20 de Abril de 2013 14:13:52 UTC+1, André Nunes escreveu: